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
