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]

Date:	Sat, 23 Aug 2014 00:48:46 +0200
From:	Peter Hüwe <PeterHuewe@....de>
To:	Jason Gunthorpe <jgunthorpe@...idianresearch.com>
Cc:	Scot Doyle <lkml14@...tdoyle.com>,
	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,
	semenzato@...gle.com
Subject: Re: [PATCH] tpm_tis: Verify ACPI-specified interrupt

CC: Luigi, he works at Google and is responsible for the TPMs in 
Chromebooks ;)

Thanks,
Peter

Am Freitag, 22. August 2014, 22:32:41 schrieb Jason Gunthorpe:
> 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/