linux-kernel - Re: [PATCH] KEYS: trusted: Use get

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <aT-uHgyYw3XhFasi@kernel.org>
Date: Mon, 15 Dec 2025 08:43:42 +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 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 the case of sealed data objects, this not the case.

> 
> Regards,
> 
> James
>  

BR, Jarkko