On Tue May 21, 2024 at 5:56 PM EEST, James Bottomley wrote: > On Tue, 2024-05-21 at 17:35 +0300, Jarkko Sakkinen wrote: > > On Tue May 21, 2024 at 5:26 PM EEST, Jarkko Sakkinen wrote: > > > On Tue May 21, 2024 at 5:13 PM EEST, James Bottomley wrote: > > > > On Tue, 2024-05-21 at 17:02 +0300, Jarkko Sakkinen wrote: > > > > > Secondly, it also roots to the null key if a parent is not > > > > > given. So it covers all the basic features of the HMAC patch > > > > > set. > > > > > > > > I don't think that can work. The key file would be wrapped to > > > > the parent and the null seed (and hence the wrapping) changes > > > > with every reboot. If you want a permanent key, it has to be in > > > > one of the accessible permanent hierarchies (storage ideally or > > > > endorsement). > > > > > > I'm fully aware that null seed is randomized per power cycle. > > OK, as long as this gets documented, I'm OK with it > > > > The fallback was inherited from James Prestwood's original code and > > > I decided to keep it as a testing feature, and also to test HMAC > > > changes. > > > > > > If you look at the testing transcript in the cover letter, it > > > should beobvious that a primary key is created in my basic test. > > > > I think what could be done to it in v3 would be to return -EOPNOTSUPP > > if parent is not defined. I.e. rationale here is that this way the > > empty option is still usable for something in future kernel releases. > > You can absolutely have null derived parent keys (I use them for > testing as well). However, the spec says the parent handle in that > case should be TPM_RH_NULL (i.e. 0x40000007) not zero: > > https://www.hansenpartnership.com/draft-bottomley-tpm2-keys.html#name-parent Yep. I somehow recalled that it replaced 0x0 with RH_NULL but it actually checked whether the handle is RH_NULL and then loaded the null key if that was the case. BR, Jarkko
