linux-kernel - Re: [tpmdd-devel] [PATCH] TPM: Work around buggy TPMs that block during continue self test

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:	Tue, 22 Jan 2013 17:29:23 -0600
From:	Kent Yoder <shpedoikal@...il.com>
To:	Jason Gunthorpe <jgunthorpe@...idianresearch.com>
Cc:	linux-kernel@...r.kernel.org, tpmdd-devel@...ts.sourceforge.net
Subject: Re: [tpmdd-devel] [PATCH] TPM: Work around buggy TPMs that block
 during continue self test

Hi Jason,

On Wed, Nov 21, 2012 at 3:15 PM, Jason Gunthorpe
<jgunthorpe@...idianresearch.com> wrote:
> We've been testing an alternative TPM for our embedded products and
> found random kernel boot failures due to time outs after the continue
> self test command.
>
> This was happening randomly, and has been *very* hard to track down, but it
> looks like with this chip there is some kind of race with the tpm_tis_status()
> check of TPM_STS_COMMAND_READY. If things get there 'too fast' then
> it sees the chip is ready, or tpm_tis_ready() works. Otherwise it takes
> somewhere over 400ms before the chip will return TPM_STS_COMMAND_READY.
>
> Adding some delay after tpm_continue_selftest() makes things reliably
> hit the failure path, otherwise it is a crapshot.

  I've staged this patch here, please test:

https://github.com/shpedoikal/linux.git tpmdd-01-22-13

Thanks,
Kent
--
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/