[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <1981bcdad096a820accf3a783181ae366cf2f8dd.camel@HansenPartnership.com>
Date: Tue, 16 Dec 2025 07:48:20 +0100
From: James Bottomley <James.Bottomley@...senPartnership.com>
To: Jarkko Sakkinen <jarkko@...nel.org>, Eric Biggers <ebiggers@...nel.org>
Cc: linux-integrity@...r.kernel.org, David Howells <dhowells@...hat.com>,
Paul Moore <paul@...l-moore.com>, James Morris <jmorris@...ei.org>, "Serge
E. Hallyn" <serge@...lyn.com>, Mimi Zohar <zohar@...ux.ibm.com>, "open
list:KEYS/KEYRINGS" <keyrings@...r.kernel.org>, "open list:SECURITY
SUBSYSTEM" <linux-security-module@...r.kernel.org>, open list
<linux-kernel@...r.kernel.org>, "Jason A. Donenfeld" <Jason@...c4.com>
Subject: Re: [PATCH] KEYS: trusted: Use get_random-fallback for TPM
On Mon, 2025-12-15 at 23:09 +0200, Jarkko Sakkinen wrote:
> Using combined entropy also decreases corrateral damage caused by
> e.g., a buggy TPM firmware, which does happen sometimes in the wild.
Just to allay concerns on this point: the random number generator of a
physical TPM is always based on a hardware entropy generating element.
NIST specifies (and FIPS testing requires) that this hardware element
conform to SP 800-90B which is about 84 pages of how a RNG should be
conditioned and tested (and certified), so there should be very little
chance of issues here.
While TPMs have had problems caused by buggy firmware in the past, it's
always affected areas that the FIPS testing doesn't cover in such depth
(like the Infineon weak prime problem). People should feel confident
in the TPM random number generator (particularly because it's the
primary boot time entropy source for the in-kernel RNG on most
laptops).
Regards,
James
Powered by blists - more mailing lists