Re: [PATCH v2] keys/trusted_keys: reuse TPM version in option handling

[Jarkko Sakkinen <jarkko@kernel.org>]

On Mon, Oct 05, 2026 at 10:38:32PM +0300, Jarkko Sakkinen wrote:
> On Mon, Oct 05, 2026 at 10:01:32AM -0500, Serge E. Hallyn wrote:
> > On Mon, Oct 05, 2026 at 11:31:46AM +0530, Srish Srinivasan wrote:
> > > Hi Jarkko,
> > > 
> > > On 10/5/26 8:54 AM, Jarkko Sakkinen wrote:
> > > > On Fri, Oct 02, 2026 at 12:40:50PM +0530, Srish Srinivasan wrote:
> > > > > Determine the TPM version once in the seal and unseal paths and reuse it
> > > > > when allocating and parsing trusted key options. This avoids redundant TPM
> > > > > version checks.
> > > > So this is a bit nitpicking perhaps but a patch that would just clean
> > > > the code up a bit would not be be worth of applying. Almost anything
> > > > that "does nothing" goes to that bin.
> > > > 
> > > > What I'm saying is that the conclusion in the last sentence goes to
> > > > wrong direction but luckily the change has also feasible effects that
> > > > we care about.
> > > > 
> > > > By caching tpm_is_tpm2() there are less fallible sites in the key
> > > > creation process, and reduced number of roundtrips with the TPM chip.
> > > > 
> > > > Or from blackbox perspective it reduces I/O traffic between kernel
> > > > and the hardware platform.
> > > 
> > > 
> > > Yes, that makes sense. Thank you for pointing this out.
> > > 
> > > I will revise the commit message to highlight the reduced failure
> > > surface and I/O between the kernel and the TPM, and
> > > send v3.
> > 
> > And I've seen chips where every round trip is a roll of the dice as
> > to whether the chip will become useless till next reboot, so that is
> > a bigger win than I was first thinking.
> 
> This is true and happens quite often. And in CPU companies in fact all
> the time with early FPGA implementations and very early ASIC based
> software development platforms.
> 
> We also have opt-in bus encryption feature where extra roundtrips have
> a horrible time cost.
> 
> Roundtrip removals are high value patches for both R&D and production,
> and they are always most welcome.

Serge, your comment reminded me of hwrng. In my opinion TPM driver
should limit itself randomness supply because it could have positive
effect on some issues that people are having [1]. hwrng can never
properly control TPM as it is behind abstraction.

I think there should be a tpm_chip associated pool of randomness. This
pool is filled with some timer triggering with a constant frequency. On
each iteration, it is filled with best effort i.e. with a single
TPM2_GetRandom invocation.

Then hwrng_fill is also filled with best effort from the pool without
any TPM interaction.

This would be an architecture that would be vastly easier to deduce
than the one which we have now, which is more unstable, which is
bad considering e.g., latency peaks and whatnot.

This basic idea can be improved with a low watermark: when going 
below it hwrng_fillfn would start the timer. I don't think high
watermark is needed as pool can be always filled just up to its
size.

I had this idea already 3-4 years ago but had forgotten about it.

[1] https://bugzilla.kernel.org/show_bug.cgi?id=217890

Br, Jarkkko