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: <20140822203241.GB1733@obsidianresearch.com>
Date:	Fri, 22 Aug 2014 14:32:41 -0600
From:	Jason Gunthorpe <jgunthorpe@...idianresearch.com>
To:	Scot Doyle <lkml14@...tdoyle.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, Aug 22, 2014 at 08:17:27PM +0000, Scot Doyle wrote:
> 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.

I remain somewhat confused - there have already been TPM patches for
Chromebooks from Google - presumably the TPM actually does work
fine. Make sure you are using a Linux with the ATMEL timeout fix, that
is particularly applicable to Chromebooks IIRC.

And again, the driver uses interrupts when booting, so I'm somewhat
confused what the problem is. I wouldn't think the driver would
successfully attach if interrupts were enabled but the interrupt
didn't work? Can you elaborate on what is going on during boot with
the interrupt, and the boot time GET_DURATIONS and TPM_STARTUP
sequences?

Perhaps the driver is timing out all commands and going ahead and
attaching anyhow? If this is the case I think we'd get a good result
if we just fixed that and had the driver simply not attach. Then your
resume will not be broken.

> > 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?

So, if you are booting the Chromebook in some weird way, is this a
problem that can be addressed by patching SeaBIOS instead of the
kernel? The internet says the SeaBIOS payload is replaceable on the
Chromebook.

Can it fix the ACPI tables to be correct before lauching Linux?

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

Testing the interrupt and failing driver attach if it doesn't work
seems very reasonable to me, I would view that as a bug fix in the driver.

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/