Dave Jiang <[email protected]> wrote:
> New:
> 1. userspace inject key into kernel keyring
I presume this step is what you do to use the nvdimm? If so, this can use
request_key() and then splice the key across to the kernel keyring.
> 2. userspace triggers update with new key id and old key id
> 3. kernel looks up keys with key-id in kernel
> 4. kernel tries to update with hardware
> 5. on success kernel accepts new key (or update old key payload)
... and splices the key into the kernel keyring.
> Also, unlock right now basically is a request-key to userspace to retrieve
> the key before we unlock. If we go the other way it sounds like we need to
> inject all the keys from userspace first before unlock can happen?
No, you'd still use request_key() for that.
It's the change-password event that I'm suggesting you should use two
explicitly nominated keys for.
> I do think associating with the current key id with the nvdimm object
> can make things a lot easier and I can just do key_lookup() instead of
> calling request_key().
You shouldn't be using key_lookup().
> What about:
> 1. user triggers update through sysfs
> 2. kernel fetches old key with key-id that's associated with the nvdimm
> object from keyring
You can do that. You'd use key_search() for that.
> 3. kernel request_key from userspace for new key
This bit I quibble with. I think you should specify it to make sure that you
get the password you intended and don't pick something else up by accident.
> 4. kernel sends both payloads to hardware to attempt update
> 5. on success kernel invalidates old key and updates key-id associated
> with the nvdimm object
I think you should just link the new key across. It should have the same
description as the old key to the kernel keyring. This would displace the
old key automatically.
> ... lookup the key via key-id ...
You shouldn't use key IDs within the kernel, except at the UAPI boundary. You
should be using the key description as the handle - and, in this case, it
should be an identifier you can match uniquely within the system with the
particular nvdimm.
David
_______________________________________________
Linux-nvdimm mailing list
[email protected]
https://lists.01.org/mailman/listinfo/linux-nvdimm
