linux-kernel - Re: [PATCH] 2.6.26-mmotm tpm-correct-tpm-timeouts-to-jiffies-conversion-d820-fix.patch

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] [day] [month] [year] [list]

Date:	Fri, 15 Aug 2008 05:39:05 -0400
From:	Valdis.Kletnieks@...edu
To:	Marcin Obara <marcin_obara@...rs.sourceforge.net>
Cc:	Andrew Morton <akpm@...ux-foundation.org>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	linux-kernel@...r.kernel.org, Marcel Selhorst <tpm@...horst.net>,
	Kylene Jo Hall <kjhall@...ibm.com>,
	tpmdd-devel@...ts.sourceforge.net
Subject: Re: [PATCH] 2.6.26-mmotm tpm-correct-tpm-timeouts-to-jiffies-conversion-d820-fix.patch

On Sat, 26 Jul 2008 20:27:33 BST, Marcin Obara said:

> Value in  chip->vendor.duration[TPM_SHORT]  is in jiffies not in  milliseconds.
>  (As I know it's not the same. Jiffy is in range 1-10 ms.)
> I know the result may be the same, but it is unclear.

I suppose I could have worded the comment block better - the intent was to
point out what the Broadcom chip returns, but by that point in the code
we're dealing with jiffies...

> Maybe... value should be compared (to 1000) before conversion?

Actually, that's probably a better idea, because my kernel is built with
HZ=1000 - usecs_to_jiffies will do something different than ==1 for HZ=100
or HZ=250 or other odd values.

> If after conversion, there should be something like this:
>        if (chip->vendor.duration[TPM_SHORT]  < (HZ/100))  /*  less
> than 10ms ? */
>                chip->vendor.duration[TPM_SHORT] = HZ;

That's another option as well, that does the right thing for various HZ values.

> What do you think?

Let me go cook up and test another iteration of the patch, will probably be
a few hours...

Content of type "application/pgp-signature" skipped