linux-kernel - Re: 2.6.23-rc1-mm1 - seems OK on Dell Latitude D820, except for tpm

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: <5208.1185508832@turing-police.cc.vt.edu>
Date:	Fri, 27 Jul 2007 00:00:32 -0400
From:	Valdis.Kletnieks@...edu
To:	Andrew Morton <akpm@...ux-foundation.org>
Cc:	Kylene Hall <kjhall@...ibm.com>, linux-kernel@...r.kernel.org,
	tpm@...horst.net
Subject: Re: 2.6.23-rc1-mm1 - seems OK on Dell Latitude D820, except for tpm_tis

On Wed, 25 Jul 2007 20:37:37 PDT, Andrew Morton said:

> I can't imagine what we did to break tpm_tis, sorry.  Nothing has changed
> in there for ages.
> 
> Perhaps something broke at the bus level.  It would be useful to add

OK, so I made a more intrusive printk-all-over patch to track what it was
doing, and got several tests in under 2.6.22-rc6-mm1 and 2.6.23-rc1-mm1.

I've attached:

debug.22-rc6-mm1 - things apparently working under the previous kernel.
debug.rc1-a      - this one complained but didn't time out for long times. I've
                 only seen 23-rc1-mm1 *not* take timeouts this one time. Oddness.
debug.rc1-b      - this one complained, and took 2 120-second waits
debug.patch      - the printf's I added, for those who want to follow along..

Apparently, things go pear-shaped in tis_tpm_send(), when they get to the
'if (chip->vendor.irq)' - under 22-rc6-mm1, we never got into this code,
because earlier initialization complained it couldn't get IRQ8.  Now, we
get IRQ3, and apparently get into this if statement, and then spend 120
seconds while wait_for_stat() times out.  So the root cause does look like
it's this IRQ8/IRQ3 issue.

I'll try to find time to do a bisect on -rc1-mm1 tomorrow to track down
what exactly did this.

(And remember to keep in mind the very real possibility that in fact, both
releases are broken in different ways - I've never actually *done* anything
with the chip further than "the driver loads".  Anybody got a very basic
userspace program to test-harness /dev/tpm0 (open, do a few test calls, close)?

View attachment "debug.22-rc6-mm1" of type "text/plain " (8092 bytes)

View attachment "debug.rc1-a" of type "text/plain " (2395 bytes)

View attachment "debug.rc1-b" of type "text/plain " (2377 bytes)

Download attachment "debug.patch" of type "application/x-patch " (3488 bytes)

Content of type "application/pgp-signature" skipped