Re: [PATCH] KEYS: trusted: Use get_random-fallback for TPM

[Jarkko Sakkinen <jarkko@kernel.org>]

On Mon, Dec 15, 2025 at 04:55:58PM +0900, James Bottomley wrote:
> 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.

I understand being "FIPS certified" embedding the premise that kernel
is also FIPS certified, which covers also crypto etc. This is the case
with enterprise kernels.

I have understanding FIPS certification dies at the point when random
data is acquired by a kernel, which is not FIPS certified. It's not 
really a safe closure.

Using same code path for RNG universally should actually help with any
certification processes.

> 
> > 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.

I don't disagree on benefits of FIPS certification.

> 
> 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?

Generally removing any non-mandatory TPM traffic is a feasible idea.

This was just something low-hanging fruit that I spotted while working
on larger patch set.

BR, Jarkko

> 
> Regards,
> 
> James
> 
> 
> 

BR, Jarkko