On Sun Mar 31, 2024 at 7:52 PM EEST, Gabríel Arthúr Pétursson wrote: > On Sun, 2024-03-31 at 19:00 +0300, Jarkko Sakkinen wrote: > > Null key is not provisioned, what is the motivation here? > > The terms here, to create a key and to provision a key, are almost > interchangeable. The latter merely implies the additional step of > saving the key to NVRAM and making it available through a persistent > handle. > > The template, aside from defining what kind of key we want to create, > is fed into the TPM's KDF used to generate the key. Different template, > different key. > > Userspace will want to recreate the same key the kernel has, thus must > use the same template. Which template shall be used then? I don't disagree with you, nor did when sending the first response :-) Downstream seems to break that guide tho. E.g. Ubuntu uses 0x80100001 NV index for storage key unsealing the key slot with PCR values. I did some time ago a quick VM install of Ubuntu just to see how it uses TPM2. I got: $ sudo tpm2_getcap handles-persistent - 0x81000001 - 0x81010001 0x81010001 is according to provisioning guide EK handle but Ubuntu uses it for completely different purpose. What I would like to understand when it comes to the provisioning guide is how important it is in reality? I have no information at this point is e.g. systemd-boot going to follow it but would like to know. > > + /* > + * create the template. Note: in order for userspace to > + * verify the security of the system, it will have to create > + * and certify this NULL primary, meaning all the template > + * parameters will have to be identical, so conform exactly to > + * the TCG TPM v2.0 Provisioning Guidance for the SRK ECC > + * key > + */ > > The TPM specifications have a standardized set of templates for the > Endorsement Keys, and a recommendation on a template to > create/provision the shared SRK. > > Why not use that one then, above something else? We are required to use > a template for key generation after all, might as well pick the one > most fitting from the standards. > > That's at least my understanding of the author's motivation. Yeah, not necessarily disagree with this or I'm somewhat aligned to this view. Ubuntu's architecture confuses me so would like to understand the magnitude of the provisioning guide. > > > So for the time being the patch set is NAK just because we lack > > clear definition of done here. I revisit it only when I know how > > to test it. > > I want to note that I'm not affiliated with the patches' author. I'm > merely an outside observer who has taken interest in the proposed > changes. Wanted to share my thoughts. BR, Jarkko
