linux-kernel - Re: [tpmdd-devel] TPM drivers support and Linux Integrity Module for 2.6.30

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: <1245442176.31915.49.camel@blackbox>
Date:	Fri, 19 Jun 2009 17:09:36 -0300
From:	Rajiv Andrade <srajiv@...ux.vnet.ibm.com>
To:	Eric Paris <eparis@...hat.com>
Cc:	"\"dds" (☕)" <dds@...gle.com>,
	seiji.munetoh@...il.com, tpmdd-devel@...ts.sourceforge.net,
	Mimi Zohar <zohar@...ux.vnet.ibm.com>,
	linux-kernel <linux-kernel@...r.kernel.org>,
	Shahbaz Khan <shaz.linux@...il.com>
Subject: Re: [tpmdd-devel] TPM drivers support and Linux Integrity Module
 for 2.6.30

On Tue, 2009-06-16 at 16:49 -0400, Eric Paris wrote:
> On Mon, 2009-06-15 at 18:42 -0300, Rajiv Andrade wrote:
> > > 2- Forget manufacturer_id and base the decision on the PNP_ID as david
> > > suggested. I previously considered it but since it would end up in
> > > modifying tpm_tis_init() prototype (struct device * to struct pnp_dev *)
> > > and then wouldn't work when loading as a module with force option on, so
> > > I moved to the manufacturer_id approach.
> > >
> > > I'll get back to #2 meanwhile and post the patch, seems not hard to
> > > accomplish though..
> > >   
> > Yes, it wasn't hard, at all, just get the id with to_pnp_dev(dev)->id.
> > 
> > However, the chip is buggy, there's no reason to make a compliant
> > upstream code modify its behavior just due an 'exception' for a not
> > compliant hardware.
> > No need to worry about it too though, the workaround is available as I
> > pointed earlier (Seiji's)...
> 
> Wait what?  we refuse to work around buggy hardware that is shipping in
> LOTS of hardware (all the currently shipping lenovo thinkpads) even
> though the fix is easy?  This doesn't sound right.....

I didn't refuse to work on it... That depends on the meaning in this
context. My point is: not make an exception in the upstream code due a
buggy hardware (that's what that easy 'fix' does). Other than David's
patches, there is a workaround available as I said: 

http://sourceforge.net/mailarchive/message.php?msg_name=f02dbbe70812012308n32dc9fd6hd1f04d3ef6e002b7%40mail.gmail.com 

The only Lenovo thinkpad model I know that has it is the X200. If Intel
is indeed still shipping it buggy (therefore more and more unaware users
are buying it), that's another story. Can you confirm that?
The best would be to hear something from Intel, if they are planning to
fix it, discontinue it, do nothing about it or anything else.
Do you know how to do it or if that's possible?

More, that's only one bug. With the workaround in hands and being able
to load the module, did you run any regression tests? (Sorry for asking
that, but, again, I don't have this chip):

Thanks,
Rajiv


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