Message-ID: <60cf8bd2afbad5e930119d73ccf069e95ee4fd9d.camel@HansenPartnership.com>
Date: Mon, 15 Dec 2025 16:55:58 +0900
From: James Bottomley <James.Bottomley@...senPartnership.com>
To: Jarkko Sakkinen <jarkko@...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>
Subject: Re: [PATCH] KEYS: trusted: Use get_random-fallback for TPM

On Mon, 2025-12-15 at 08:43 +0200, Jarkko Sakkinen wrote:
> On Mon, Dec 15, 2025 at 07:18:41AM +0900, James Bottomley wrote:
> > On Sun, 2025-12-14 at 23:32 +0200, Jarkko Sakkinen wrote:
> > > 1. tpm2_get_random() is costly when TCG_TPM2_HMAC is enabled and
> > > thus its use should be pooled rather than directly used. This
> > > both reduces latency and improves its predictability.
> > > 
> > > 2. Linux is better off overall if every subsystem uses the same
> > > source for the random bistream as the de-facto choice, unless
> > > *force majeure* reasons point to some other direction.
> > > 
> > > In the case, of TPM there is no reason for trusted keys to invoke
> > > TPM directly.
> > 
> > That assertion isn't correct: you seem to have forgotten we had
> > this argument six or seven years ago, but even that was a reprise
> > of an even earlier one.  Lore doesn't go back far enough for the
> > intermediate one on the tpm list, but the original was cc'd to
> > lkml:
> > 
> > https://lore.kernel.org/all/1378920168.26698.64.camel@localhost/
> > 
> > The decision then was to use the same random source as the key
> > protection.  Unfortunately most of the active participants have
> > moved on from IBM and I don't have their current email addresses,
> > but the bottom line is there were good reasons to do trusted keys
> > this way that your assertions above don't overcome.  I'm not saying
> > we shouldn't reconsider the situation, but we need a reasoned
> > debate rather than simply doing it by fiat.
> 
> The way I see this is that given that kernel is not running inside
> TPM, FIPS certification of the RNG does not have any measurable
> value.
> 
> Random data generation should happen as part of object creation
> process i.e. should be fully self-contained process within the TPM in
> order for FIPS to matter.

In FIPS terms, there's no distinction between keeping the whole
generation process internal to the TPM and using the FIPS certified rng
of the TPM to source the contents of a kernel protected key.  Both
provide equally valid, and FIPS certified data.

> In the case of sealed data objects, this not the case.

FIPS is concerned with origins and provenance, so it most certainly is
the case even for trusted keys.  However, if the Kernel RNG is fips
certified (as can happen with certain FIPS modules) it is the case that
either the Kernel or TPM RNG would satisfy the FIPS requirement.  The
question for trusted key users is really do they always want the TPM
FIPS RNG or should we allow mixing with the kernel RNG even in the non-
FIPS case.

Perhaps, rather than getting hung up on FIPS sources and to facilitate
debating the bedrock requirements, we could turn this around and ask
what the use case you have for using the in-kernel RNG is?

Regards,

James

Powered by blists - more mailing lists