[PATCH v2] keys/trusted_keys: reuse TPM version in option handling
Jarkko Sakkinen
jarkko at kernel.org
Mon Oct 5 19:38:26 UTC 2026
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.
Br, Jarkko
More information about the Linux-security-module-archive
mailing list