Since we cannot at this point cache names of the keys given limitations
of the ASN.1 file format, I'll start a fresh patch set. Let's fixup what
we can right now.

This patch set addresses two major issues in the feature:

1. Dynamic resolution without gain. All kernel sites have at most single
   handle to authorize. Even if this changes some day this is how it is
   as of today and we definitely do not want to dictate the future but
   instead downscale code to the metrics that we have as of today.
2. Eliminate at least one unnnecessary tpm2_read_public() call.

Jarkko Sakkinen (5):
  KEYS: trusted: Remove dead branch from tpm2_unseal_cmd
  tpm2-sessions: Define TPM2_NAME_MAX_SIZE
  KEYS: trusted: Re-orchestrate tpm2_read_public() calls
  tpm2-sessions: Remove AUTH_MAX_NAMES
  tpm-buf: Remove tpm_buf_append_handle

 drivers/char/tpm/tpm-buf.c                |  25 ----
 drivers/char/tpm/tpm-sysfs.c              |   2 +-
 drivers/char/tpm/tpm2-cmd.c               |   9 +-
 drivers/char/tpm/tpm2-sessions.c          | 130 ++++++---------------
 include/linux/tpm.h                       |  49 +++++---
 security/keys/trusted-keys/trusted_tpm2.c | 134 +++++++++++++---------
 6 files changed, 155 insertions(+), 194 deletions(-)

-- 
2.52.0

On Tue, Dec 09, 2025 at 12:05:23PM +0200, Jarkko Sakkinen wrote:
> Since we cannot at this point cache names of the keys given limitations
> of the ASN.1 file format, I'll start a fresh patch set. Let's fixup what
> we can right now.
> 
> This patch set addresses two major issues in the feature:
> 
> 1. Dynamic resolution without gain. All kernel sites have at most single
>    handle to authorize. Even if this changes some day this is how it is
>    as of today and we definitely do not want to dictate the future but
>    instead downscale code to the metrics that we have as of today.
> 2. Eliminate at least one unnnecessary tpm2_read_public() call.
> 
> Jarkko Sakkinen (5):
>   KEYS: trusted: Remove dead branch from tpm2_unseal_cmd
>   tpm2-sessions: Define TPM2_NAME_MAX_SIZE
>   KEYS: trusted: Re-orchestrate tpm2_read_public() calls
>   tpm2-sessions: Remove AUTH_MAX_NAMES
>   tpm-buf: Remove tpm_buf_append_handle
> 
>  drivers/char/tpm/tpm-buf.c                |  25 ----
>  drivers/char/tpm/tpm-sysfs.c              |   2 +-
>  drivers/char/tpm/tpm2-cmd.c               |   9 +-
>  drivers/char/tpm/tpm2-sessions.c          | 130 ++++++---------------
>  include/linux/tpm.h                       |  49 +++++---
>  security/keys/trusted-keys/trusted_tpm2.c | 134 +++++++++++++---------
>  6 files changed, 155 insertions(+), 194 deletions(-)
> 
> -- 
> 2.52.0
> 

For hwrng we can e.g., calculate factor by timing tpm2_get_random() with
and without HMAC encryption. Then we can use this as frequency how often 
data is pulled.

The other angle to combine this is to maintain largeish FIFO of random 
bytes and fill this when it goes below a treshold. 

Probably some combination of these will provide answer to performance
and latency problem with hwrng when HMAC encryption is turned on:

1. The first amortizes the overall quota.
2. Second provides constant latency without major spikes.

BR, Jarkko

On Tue, Dec 09, 2025 at 05:42:55PM +0200, Jarkko Sakkinen wrote:
> On Tue, Dec 09, 2025 at 12:05:23PM +0200, Jarkko Sakkinen wrote:
> > Since we cannot at this point cache names of the keys given limitations
> > of the ASN.1 file format, I'll start a fresh patch set. Let's fixup what
> > we can right now.
> > 
> > This patch set addresses two major issues in the feature:
> > 
> > 1. Dynamic resolution without gain. All kernel sites have at most single
> >    handle to authorize. Even if this changes some day this is how it is
> >    as of today and we definitely do not want to dictate the future but
> >    instead downscale code to the metrics that we have as of today.
> > 2. Eliminate at least one unnnecessary tpm2_read_public() call.
> > 
> > Jarkko Sakkinen (5):
> >   KEYS: trusted: Remove dead branch from tpm2_unseal_cmd
> >   tpm2-sessions: Define TPM2_NAME_MAX_SIZE
> >   KEYS: trusted: Re-orchestrate tpm2_read_public() calls
> >   tpm2-sessions: Remove AUTH_MAX_NAMES
> >   tpm-buf: Remove tpm_buf_append_handle
> > 
> >  drivers/char/tpm/tpm-buf.c                |  25 ----
> >  drivers/char/tpm/tpm-sysfs.c              |   2 +-
> >  drivers/char/tpm/tpm2-cmd.c               |   9 +-
> >  drivers/char/tpm/tpm2-sessions.c          | 130 ++++++---------------
> >  include/linux/tpm.h                       |  49 +++++---
> >  security/keys/trusted-keys/trusted_tpm2.c | 134 +++++++++++++---------
> >  6 files changed, 155 insertions(+), 194 deletions(-)
> > 
> > -- 
> > 2.52.0
> > 
> 
> For hwrng we can e.g., calculate factor by timing tpm2_get_random() with
> and without HMAC encryption. Then we can use this as frequency how often 
> data is pulled.
> 
> The other angle to combine this is to maintain largeish FIFO of random 
> bytes and fill this when it goes below a treshold. 
> 
> Probably some combination of these will provide answer to performance
> and latency problem with hwrng when HMAC encryption is turned on:
> 
> 1. The first amortizes the overall quota.
> 2. Second provides constant latency without major spikes.

Another perhaps more unorthodox idea:

1. Calculate factor as said above. Let's call it N.
2. Every Nth step seed a pseudo rng from TPM.
3. On steps not divisible by N, pull from pseud rng.

I'm not a cryptographer but would randomness suffer from this? Then the
seeds that woud come from TPM are HMAC encrypted at least without major 
hits on performance.

Just enumerated this. Not sure about this idea yet by any means but I do 
like simplicy of it (and that also makes me concerned about missed
details).

BR, Jarkko

On Tue, Dec 09, 2025 at 07:32:27PM +0200, Jarkko Sakkinen wrote:
> On Tue, Dec 09, 2025 at 05:42:55PM +0200, Jarkko Sakkinen wrote:
> > On Tue, Dec 09, 2025 at 12:05:23PM +0200, Jarkko Sakkinen wrote:
> > > Since we cannot at this point cache names of the keys given limitations
> > > of the ASN.1 file format, I'll start a fresh patch set. Let's fixup what
> > > we can right now.
> > > 
> > > This patch set addresses two major issues in the feature:
> > > 
> > > 1. Dynamic resolution without gain. All kernel sites have at most single
> > >    handle to authorize. Even if this changes some day this is how it is
> > >    as of today and we definitely do not want to dictate the future but
> > >    instead downscale code to the metrics that we have as of today.
> > > 2. Eliminate at least one unnnecessary tpm2_read_public() call.
> > > 
> > > Jarkko Sakkinen (5):
> > >   KEYS: trusted: Remove dead branch from tpm2_unseal_cmd
> > >   tpm2-sessions: Define TPM2_NAME_MAX_SIZE
> > >   KEYS: trusted: Re-orchestrate tpm2_read_public() calls
> > >   tpm2-sessions: Remove AUTH_MAX_NAMES
> > >   tpm-buf: Remove tpm_buf_append_handle
> > > 
> > >  drivers/char/tpm/tpm-buf.c                |  25 ----
> > >  drivers/char/tpm/tpm-sysfs.c              |   2 +-
> > >  drivers/char/tpm/tpm2-cmd.c               |   9 +-
> > >  drivers/char/tpm/tpm2-sessions.c          | 130 ++++++---------------
> > >  include/linux/tpm.h                       |  49 +++++---
> > >  security/keys/trusted-keys/trusted_tpm2.c | 134 +++++++++++++---------
> > >  6 files changed, 155 insertions(+), 194 deletions(-)
> > > 
> > > -- 
> > > 2.52.0
> > > 
> > 
> > For hwrng we can e.g., calculate factor by timing tpm2_get_random() with
> > and without HMAC encryption. Then we can use this as frequency how often 
> > data is pulled.
> > 
> > The other angle to combine this is to maintain largeish FIFO of random 
> > bytes and fill this when it goes below a treshold. 
> > 
> > Probably some combination of these will provide answer to performance
> > and latency problem with hwrng when HMAC encryption is turned on:
> > 
> > 1. The first amortizes the overall quota.
> > 2. Second provides constant latency without major spikes.
> 
> Another perhaps more unorthodox idea:
> 
> 1. Calculate factor as said above. Let's call it N.
> 2. Every Nth step seed a pseudo rng from TPM.
> 3. On steps not divisible by N, pull from pseud rng.
> 
> I'm not a cryptographer but would randomness suffer from this? Then the
> seeds that woud come from TPM are HMAC encrypted at least without major 
> hits on performance.
> 
> Just enumerated this. Not sure about this idea yet by any means but I do 
> like simplicy of it (and that also makes me concerned about missed
> details).

Third option would be to have simply a kthread with a rate that fills a
pool and hwrng callbacks serves from that pool. If there is no bytes,
there is no bytes (which is fine as far as API is concerned).

This has optimal system latency properties I'd figure.

BR, Jarkko

On Tue, Dec 09, 2025 at 08:27:25PM +0200, Jarkko Sakkinen wrote:
> On Tue, Dec 09, 2025 at 07:32:27PM +0200, Jarkko Sakkinen wrote:
> > On Tue, Dec 09, 2025 at 05:42:55PM +0200, Jarkko Sakkinen wrote:
> > > On Tue, Dec 09, 2025 at 12:05:23PM +0200, Jarkko Sakkinen wrote:
> > > > Since we cannot at this point cache names of the keys given limitations
> > > > of the ASN.1 file format, I'll start a fresh patch set. Let's fixup what
> > > > we can right now.
> > > > 
> > > > This patch set addresses two major issues in the feature:
> > > > 
> > > > 1. Dynamic resolution without gain. All kernel sites have at most single
> > > >    handle to authorize. Even if this changes some day this is how it is
> > > >    as of today and we definitely do not want to dictate the future but
> > > >    instead downscale code to the metrics that we have as of today.
> > > > 2. Eliminate at least one unnnecessary tpm2_read_public() call.
> > > > 
> > > > Jarkko Sakkinen (5):
> > > >   KEYS: trusted: Remove dead branch from tpm2_unseal_cmd
> > > >   tpm2-sessions: Define TPM2_NAME_MAX_SIZE
> > > >   KEYS: trusted: Re-orchestrate tpm2_read_public() calls
> > > >   tpm2-sessions: Remove AUTH_MAX_NAMES
> > > >   tpm-buf: Remove tpm_buf_append_handle
> > > > 
> > > >  drivers/char/tpm/tpm-buf.c                |  25 ----
> > > >  drivers/char/tpm/tpm-sysfs.c              |   2 +-
> > > >  drivers/char/tpm/tpm2-cmd.c               |   9 +-
> > > >  drivers/char/tpm/tpm2-sessions.c          | 130 ++++++---------------
> > > >  include/linux/tpm.h                       |  49 +++++---
> > > >  security/keys/trusted-keys/trusted_tpm2.c | 134 +++++++++++++---------
> > > >  6 files changed, 155 insertions(+), 194 deletions(-)
> > > > 
> > > > -- 
> > > > 2.52.0
> > > > 
> > > 
> > > For hwrng we can e.g., calculate factor by timing tpm2_get_random() with
> > > and without HMAC encryption. Then we can use this as frequency how often 
> > > data is pulled.
> > > 
> > > The other angle to combine this is to maintain largeish FIFO of random 
> > > bytes and fill this when it goes below a treshold. 
> > > 
> > > Probably some combination of these will provide answer to performance
> > > and latency problem with hwrng when HMAC encryption is turned on:
> > > 
> > > 1. The first amortizes the overall quota.
> > > 2. Second provides constant latency without major spikes.
> > 
> > Another perhaps more unorthodox idea:
> > 
> > 1. Calculate factor as said above. Let's call it N.
> > 2. Every Nth step seed a pseudo rng from TPM.
> > 3. On steps not divisible by N, pull from pseud rng.
> > 
> > I'm not a cryptographer but would randomness suffer from this? Then the
> > seeds that woud come from TPM are HMAC encrypted at least without major 
> > hits on performance.
> > 
> > Just enumerated this. Not sure about this idea yet by any means but I do 
> > like simplicy of it (and that also makes me concerned about missed
> > details).
> 
> Third option would be to have simply a kthread with a rate that fills a
> pool and hwrng callbacks serves from that pool. If there is no bytes,
> there is no bytes (which is fine as far as API is concerned).
> 
> This has optimal system latency properties I'd figure.

OK so the very first thing that should be done with hwrng is this: it 
should be opportunistic instead of being committing (to X number of 
bytes). Further optimizations should be considered only after changing
this heuristics.

That guarantees that when hwrng's thread queries bytes from TPM driver
it is guaranteed to cause always exactly one TPM2_GetRandom transaction.

How this can be done is to first re-orchestrate tpm_get_random() along 
the lines (out of top of my head, did not even compile this):

int tpm_get_random(struct tpm_chip *chip, u8 *out, size_t max)
{
	u32 num_bytes = max;
	u8 *out_ptr = out;
	int retries = 5;
	int total = 0;
	int rc;

	if (!out || !max || max > TPM_MAX_RNG_DATA)
		return -EINVAL;

	if (!chip)
		return -ENODEV;

	rc = tpm_try_get_ops(chip);
	if (rc)
		return rc;

	if (chip->flags & TPM_CHIP_FLAG_TPM2) {
		rc = tpm2_start_auth_session(chip);
		if (rc)
			return rc;
	}

	do {
		if (chip->flags & TPM_CHIP_FLAG_TPM2)
			rc = tpm2_get_random(chip, out_ptr, num_bytes);
		else
			rc = tpm1_get_random(chip, out_ptr, num_bytes);

		if (rc < 0)
			goto err;

		out_ptr += rc;
		total += rc;
		num_bytes -= rc;
	} while (retries-- && total < max);

	tpm_put_ops(chip);
	return total ? total : -EIO;

err:
	if (chip->flags & TPM_CHIP_FLAG_TPM2)
		tpm2_end_auth_session(chip);

	tpm_put_ops(chip);
	return rc;
}
EXPORT_SYMBOL_GPL(tpm_get_random);

{tpm1,tpm2}_get_random() are changed to do exactly single transaction
and on success they return how many bytes were read.

hwrng code should also use {tpm1,tpm2}_get_random() and use the
requested size as a hint not as something that we commit into.

I think this will benefit kernel even without HMAC encryption because
it objectively makes things a bit more deterministic.

BR, Jarkko