Message-ID: <aUBk2nUpd2V8p9qc@kernel.org>
Date: Mon, 15 Dec 2025 21:43:22 +0200
From: Jarkko Sakkinen <jarkko@...nel.org>
To: James Bottomley <James.Bottomley@...senpartnership.com>
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, Dec 15, 2025 at 10:49:15AM +0200, Jarkko Sakkinen wrote:
> 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.

I think there is misunderstanding with FIPS.

Having FIPS certificated RNG in TPM matters but it only matters only in 
the sense that callers can be FIPS certified as they use that RNG as a 
source.

Using FIPS certified RNG does not magically make callers be FIPS 
ceritified actors. The data is contaminated in that sense at the point
when kernel acquires it.

BR, Jarkko

Powered by blists - more mailing lists