On Tue May 21, 2024 at 5:35 PM EEST, Jarkko Sakkinen wrote:

On Tue May 21, 2024 at 5:26 PM EEST, Jarkko Sakkinen wrote:

quoted

On Tue May 21, 2024 at 5:13 PM EEST, James Bottomley wrote:

quoted

On Tue, 2024-05-21 at 17:02 +0300, Jarkko Sakkinen wrote:

quoted

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.

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 be
obvious 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.

It was actually like this: if you explicitly set handle to RH_NULL.
Have not used it a lot so did not recall this.

That said I'd actually just take away any special substitution logic
and use any handle given by the user space as it is.

BR, Jarkko