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@kernel.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,
 };
-- 
2.39.5

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@kernel.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@kernel.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.

- Eric

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@kernel.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@kernel.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.

> 
> - Eric

BR, Jarkko

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@kernel.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@kernel.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

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.

Regards,

James
 

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

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.

> 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.

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?

Regards,

James

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

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

On Mon, 2025-12-15 at 21:43 +0200, Jarkko Sakkinen wrote:
[...]
> 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.

I think FIPS certification is a red herring.  The point being made in
the original thread is about RNG quality.  The argument essentially
being that the quality of the TPM RNG is known at all points in time
but the quality of the kernel RNG (particularly at start of day when
the entropy pool is new) is less certain.

Regards,

James

On Mon, Dec 15, 2025 at 09:01:49PM +0100, James Bottomley wrote:
> On Mon, 2025-12-15 at 21:43 +0200, Jarkko Sakkinen wrote:
> [...]
> > 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.
> 
> I think FIPS certification is a red herring.  The point being made in
> the original thread is about RNG quality.  The argument essentially
> being that the quality of the TPM RNG is known at all points in time
> but the quality of the kernel RNG (particularly at start of day when
> the entropy pool is new) is less certain.

OK, that's fair point.

I.e., using TPM2_GetRandom here makes sense, not because of FIPS
certification per se but because it is guarantees matching entropy to
other types of keys generated with TPM2_Create (as everything uses the
same RNG).

I can buy this but think it would really make sense to add a comment to
the source code.

I was thinking something along the lines of:

/*
 * tpm_get_random() is used here directly instead of relying kernel's
 * RNG in order to match RNGs with objects generated by TPM internally.
 */

It does not mention FIPS explicitly because I think this is already
enforcing condition and thus enough. And e.g., applies also when one
uses an emulator (and thus useful tidbit for that use and purpose).

> 
> Regards,
> 
> James
> 

BR, Jarkko

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@kernel.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,
>  };
> -- 
> 2.39.5
> 

Additional cc's as this indirectly relates to hwrng.

BR, Jarkko