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: <aUB5IsJeWhFvX-cA@kernel.org>
Date: Mon, 15 Dec 2025 23:09:54 +0200
From: Jarkko Sakkinen <jarkko@...nel.org>
To: Eric Biggers <ebiggers@...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>,
	James Bottomley <James.Bottomley@...senpartnership.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>,
	"Jason A. Donenfeld" <Jason@...c4.com>
Subject: Re: [PATCH] KEYS: trusted: Use get_random-fallback for TPM

On Mon, Dec 15, 2025 at 10:35:57PM +0200, Jarkko Sakkinen wrote:
> On Mon, Dec 15, 2025 at 08:09:39PM +0000, Eric Biggers wrote:
> > On Sun, Dec 14, 2025 at 11:32:36PM +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.
> > > 
> > > Thus, unset '.get_random', which causes fallback to kernel_get_random().
> > > 
> > > Signed-off-by: Jarkko Sakkinen <jarkko@...nel.org>
> > > ---
> > >  security/keys/trusted-keys/trusted_tpm1.c | 6 ------
> > >  1 file changed, 6 deletions(-)
> > > 
> > > diff --git a/security/keys/trusted-keys/trusted_tpm1.c b/security/keys/trusted-keys/trusted_tpm1.c
> > > index 636acb66a4f6..33b7739741c3 100644
> > > --- a/security/keys/trusted-keys/trusted_tpm1.c
> > > +++ b/security/keys/trusted-keys/trusted_tpm1.c
> > > @@ -936,11 +936,6 @@ static int trusted_tpm_unseal(struct trusted_key_payload *p, char *datablob)
> > >  	return ret;
> > >  }
> > >  
> > > -static int trusted_tpm_get_random(unsigned char *key, size_t key_len)
> > > -{
> > > -	return tpm_get_random(chip, key, key_len);
> > > -}
> > > -
> > >  static int __init init_digests(void)
> > >  {
> > >  	int i;
> > > @@ -992,6 +987,5 @@ struct trusted_key_ops trusted_key_tpm_ops = {
> > >  	.init = trusted_tpm_init,
> > >  	.seal = trusted_tpm_seal,
> > >  	.unseal = trusted_tpm_unseal,
> > > -	.get_random = trusted_tpm_get_random,
> > >  	.exit = trusted_tpm_exit,
> > >  };
> > 
> > Reviewed-by: Eric Biggers <ebiggers@...nel.org>
> > 
> > Agreed that kernel code should prefer the standard Linux RNG whenever
> > possible.  Note that the standard Linux RNG already incorporates entropy
> > from hardware RNGs, when available.
> 
> I get also the argument of using TPM RNG here just for the sake of
> matching the creation with fully internally generated TPM objects.
> 
> I'm a bit little in-between what to do with this patch.
> 
> I suggested a comment to James. Other alternative would be do this
> change and update this patch with a comment:
> 
> /*
>  * tpm_get_random() was used previously here as the RNG in order to match
>  * rng with the objects generated internally inside the TPM. However, since
>  * e.g., FIPS certification requires kernel crypto and rng to be FIPS
>  * certified, formally kernel_get_random() is equally legit source for
>  * the random numbers.
>  */
> 
> It's longish but I think this fully covers the whole issue.
> 
> And if there is ever need to return to this, it's a good remainder of
> the design choices.

I'll supplement the patch with that explanatory comment. I think the
previous discussions pointed out by James were useful reflection point 
and that comment summarizes that discussion.

I'll add your reviewd-by to the next version, as no additional code 
changes will be implemented.

I think that this discussion also implies that the callback itself is
somewhat questionable, perhaps even harmful. Same arguments apply also
to e.g., TEE trusted keys. IMHO, would be overall best for Linux to a
have a one single call path for generating random numbers.

Using combined entropy also decreases corrateral damage caused by e.g.,
a buggy TPM firmware, which does happen sometimes in the wild.

BR, Jarkko