linux-kernel - Re: [PATCH] tpm_tis: Verify ACPI-specified interrupt

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <alpine.LNX.2.11.1408221924070.1046@localhost.localdomain>
Date:	Fri, 22 Aug 2014 20:17:27 +0000 (UTC)
From:	Scot Doyle <lkml14@...tdoyle.com>
To:	Jason Gunthorpe <jgunthorpe@...idianresearch.com>
cc:	Peter Huewe <peterhuewe@....de>, Ashley Lai <ashley@...leylai.com>,
	Marcel Selhorst <tpmdd@...horst.net>,
	Stefan Berger <stefanb@...ux.vnet.ibm.com>,
	tpmdd-devel@...ts.sourceforge.net, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] tpm_tis: Verify ACPI-specified interrupt

On Fri, 22 Aug 2014, Jason Gunthorpe wrote:
> On Fri, Aug 22, 2014 at 12:58:41AM +0000, Scot Doyle wrote:
>> Some machines, such as the Acer C720 and Toshiba CB35, have TPMs
>> that do not use interrupts while also having an ACPI TPM entry
>
> How do these machines work in Windows?

I don't know. Since they're Chromebooks (booted in legacy mode running 
SeaBIOS instead of depthcharge or whatever ChromeOS uses), I think they're 
mostly used to run Linux.

> Why only resume? Shouldn't every TPM command (such as the 3 or 4 the
> driver issues at startup) timeout too?

I noticed that startup(save_state) on suspend did take longer, but only 
four or five seconds instead of the 160 seconds during selftest on resume.

>> indicating a specific interrupt to be used. Since this interrupt
>> is invalid, these machines freeze on resume until the interrupt
>> times out.
>
>> Generate the ACPI-specified interrupt. If none is received, then
>> fall back to polling mode.
>
> So, this makes the IRQ detection code run unconditionally, but that
> code was only ever really used in certain old non-probable case..
>
> I wonder if it works reliably?

That is good to know. I share your concerns about reliability, not having 
the ability to test on other machines.

> In any event, I think a FIRMWARE_BUG message should be printed if this
> case is detected.

I agree.

> I'd be more comfortable with some kind of ACPI black list or patch or
> something? What is normal for handling broken ACPI?

I would be more comfortable with this general approach as well. However, 
I've had to submit several patches for individual Chromebooks related to 
backlight control since the VBT also is misconfigured. Would it be 
possible to find a blacklist mechanism that didn't require identifying 
each Chromebook separately, since they seem to have this issue on an 
ongoing basis?

dmidecode outputs:

Handle 0x0000, DMI type 0, 24 bytes
BIOS Information
        Vendor: coreboot
        Version:
        Release Date: 12/04/2013
        ROM Size: 8192 kB
        Characteristics:
                PCI is supported
                PC Card (PCMCIA) is supported
                BIOS is upgradeable
                Selectable boot is supported
                ACPI is supported
                Targeted content distribution is supported
        BIOS Revision: 4.0
        Firmware Revision: 0.0

Handle 0x0001, DMI type 1, 27 bytes
System Information
        Manufacturer: Toshiba
        Product Name: Leon
        Version: 1.0
        Serial Number: 123456789
        UUID: Not Settable
        Wake-up Type: Reserved
        SKU Number: Not Specified
        Family: Not Specified

All Chromebooks that I've seen list the BIOS vendor as 'coreboot'.

We also have access to TPM chip vendor and revision. All chromebooks that 
I've seen so far have the same vendor (11) and revision (16).

So we have five pieces of identifying information...
1. TPM chip vendor
2. TPM chip revision
3. BIOS vendor
4. System manufacturer
5. System product name

and at least two possible actions...
1. ignore the acpi interrupt
2. verify the acpi interrupt

The safest approach would be to ignore the ACPI information for systems 
matching all five identifiers.

A more general approach might be to verify the ACPI interrupt for 
systems matching the first three identifiers.

Thoughts?

> Jason
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/