[PATCH v7 0/3] Optimize tpm2_read_public() calls
Jarkko Sakkinen
jarkko at kernel.org
Mon Dec 8 05:15:23 UTC 2025
On Mon, Dec 08, 2025 at 07:06:16AM +0200, Jarkko Sakkinen wrote:
> The main goal is fairly straight-forwrd here.
>
> The aim of these patches is optimize the number of tpm2_read_public() calls
> to the bare minimum.
>
> ## About dropping 'parentName' attribute for ASN.1 keys from the patch set
>
> I wrote this section as a remainder as I have facts fresh in my mind so
> that I can return them as soon as there is working group for the ASN.1
> specification. We really need to have this in the spec.
>
> I dropped [1] given that [2] is landing shortly to IETF draft process,
> according to James Bottomley [3]. We will return to [1] as soon as draft
> process is open for comments. Still, that attribute is super important,
> and here is why.
>
> This will cause a overhead as tpm2_unseal_trusted needs to do an
> unnecessary (from pure technical perspective) TPM2_ReadPublic command to
> acquire TPM name of the parent. This is obviously known at the time of
> creation of a key but the information is not stored anywhere by the
> key format.
>
> It also aligns badly with TCG specifications as Table 6 of architecture
> spec explicitly defines a reference (or name) for transient keys,
> persistent keys and NV indexes to be TPM_ALG_ID concatenated together
> with the hash of TPMT_PUBLIC. I.e. the file format is using exactly
> the opposite what should be use as reference for keys than what it
> should use.
>
> Other benefits are of course auto-discovery of parent for a key file,
> which is nasty to do without the name pre-stored.
Right and TPMT_HA is calculated everytime when a trusted key is
created, and right after that the already calculated data is simply
thrown into dumpster. And we are talking about spec compliant way
to refer other keys here, and only 66 bytes of extra payload.
I don't get it. And neither do I get how anyone would want to fix
this issue with TPM2_CreatePrimary interception.
BR, Jarkko
More information about the Linux-security-module-archive
mailing list