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] [day] [month] [year] [list]
Message-ID: <facea3621fc240ebb05dedb0127d8a514970d40d.camel@huaweicloud.com>
Date: Thu, 29 Jan 2026 17:18:55 +0100
From: Roberto Sassu <roberto.sassu@...weicloud.com>
To: Jarkko Sakkinen <jarkko@...nel.org>, linux-integrity@...r.kernel.org
Cc: Eric Biggers <ebiggers@...nel.org>, James Bottomley
 <James.Bottomley@...senPartnership.com>, Mimi Zohar <zohar@...ux.ibm.com>, 
 David Howells <dhowells@...hat.com>, Paul Moore <paul@...l-moore.com>,
 James Morris <jmorris@...ei.org>,  "Serge E. Hallyn" <serge@...lyn.com>,
 "open list:KEYS-TRUSTED" <keyrings@...r.kernel.org>,  "open list:SECURITY
 SUBSYSTEM" <linux-security-module@...r.kernel.org>, open list
 <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH v9 01/11] KEYS: trusted: Use get_random-fallback for TPM

On Sun, 2026-01-25 at 21:25 +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
>    generating the random numbers required.
> 
> Thus, unset '.get_random', which causes fallback to kernel_get_random().
> 
> One might argue that TPM RNG should be used for the generated trusted keys,
> so that they have matching entropy with the TPM internally generated
> objects.
> 
> This argument does have some weight into it but as far cryptography goes,
> FIPS certification sets the exact bar, not which exact FIPS certified RNG
> will be used. Thus, the rational choice is obviously to pick the lowest
> latency path, which is kernel RNG.
> 
> Finally, there is an actual defence in depth benefit when using kernel RNG
> as it helps to mitigate TPM firmware bugs concerning RNG implementation,
> given the obfuscation by the other entropy sources.
> 
> Reviewed-by: Eric Biggers <ebiggers@...nel.org>
> Signed-off-by: Jarkko Sakkinen <jarkko@...nel.org>
> ---
> v7:
> - A new patch. Simplifies follow up patches.
> ---
>  security/keys/trusted-keys/trusted_tpm1.c | 16 ++++++++++------
>  1 file changed, 10 insertions(+), 6 deletions(-)
> 
> diff --git a/security/keys/trusted-keys/trusted_tpm1.c b/security/keys/trusted-keys/trusted_tpm1.c
> index 636acb66a4f6..7ce7e31bcdfb 100644
> --- a/security/keys/trusted-keys/trusted_tpm1.c
> +++ b/security/keys/trusted-keys/trusted_tpm1.c
> @@ -6,6 +6,16 @@
>   * See Documentation/security/keys/trusted-encrypted.rst
>   */
>  
> +/**
> + * DOC: Random Number Generation
> + *
> + * tpm_get_random() was previously used here as the RNG in order to have equal
> + * entropy with the objects fully inside the TPM. However, as far as goes,
> + * kernel RNG is equally fine, as long as long as it is FIPS certified. Also,
> + * using kernel RNG has the benefit of mitigating bugs in the TPM firmware
> + * associated with the RNG.
> + */

If we switch to the kernel RNG that is better, and the TPM one is
flawed, I guess we are going to have big problems anyway, since the TPM
random number generator is used by the TPM itself internally.

I think it makes sense to leave as it is.

Thanks

Roberto

> +
>  #include <crypto/hash_info.h>
>  #include <crypto/sha1.h>
>  #include <crypto/utils.h>
> @@ -936,11 +946,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 +997,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,
>  };


Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ