On Sun, Dec 07, 2025 at 03:33:17PM +0900, James Bottomley wrote: > On Fri, 2025-12-05 at 02:49 +0200, Jarkko Sakkinen wrote: > > On Fri, Dec 05, 2025 at 01:20:30AM +0200, Jarkko Sakkinen wrote: > > > On Fri, Dec 05, 2025 at 12:31:27AM +0200, Jarkko Sakkinen wrote: > > > > tpm2_load_cmd() and tpm2_unseal_cmd() use the same parent, and > > > > calls to > > > > tpm_buf_append_name() cause the exact same TPM2_ReadPublic > > > > command to be > > > > sent to the chip, causing unnecessary traffic. > > > > > > > > 1. Export tpm2_read_public in order to make it callable from > > > > 'trusted_tpm2'. > > > > 2. Re-orchestrate tpm2_seal_trusted() and tpm2_unseal_trusted() > > > > in order to > > > > halve the name resolutions required: > > > > 2a. Move tpm2_read_public() calls into trusted_tpm2. > > > > 2b. Pass TPM name to tpm_buf_append_name(). > > > > 2c. Rework tpm_buf_append_name() to use the pre-resolved name. > > > > > > > > Signed-off-by: Jarkko Sakkinen <[email protected]> > > > > > > If ASN.1 blob would contain also name of the parent then zero > > > tpm2_read_public() calls would be required i.e., the main > > > bottleneck here inherits from the limitations of the file format > > > itself. > > > > Along the lines of attached patch. > > Well firstly [6] is already being taken by the creation data proposal, > so this would introduce an incompatibility between the kernel and the > spec, but secondly, if you want something like this in the spec before > it goes to the IETF you really need to propose it now.
What is the mailing list for the working group, or is this still unclear as of today? > > The problem with this particular addition is that it would be Linux > Kernel specific. All the current TSSs already do a cached read public > under the covers when they add the session wrappings so the user facing > API they expose has nowhere to insert (or easily extract) a name field > and thus TSS based implementations would have no incentive to either > output or consume this field. That's not to say the standard can't > have additions for crazy or niche use cases (that's what the rsaParent > flag is: a one off to support a niche SUSE use case) but it would be > hard to persuade user implementations to do this so the kernel would > have to interoperate with the case where it didn't exist anyway. It is just matter of conditionally calling tpm2_read_public(). Not a big deal. > > The standard use today is with permanent handles for parents, where the > parent is created on the fly, so the name is actually returned from > TPM2_CreatePrimary for this use case. It should be a simple matter to > bring the kernel implementation up to doing this as well. Intercepting TPM2_CreatePrimary does not provide full coverage, as it does not address persistent keys, which kernel interface does support. > > Regards, > > James > > BR, Jarkko
