On Fri, Sep 21, 2018 at 5:29 PM Dave Jiang <[email protected]> wrote: [..] > > What I meant here was to use, say, nvdimm_lookup_user_key() to get a key > > from > > userspace that contains the old password. You can use the description of > > the > > key to search nvdimm_keyring for the private key and then compare the > > passwords. > > Ok I have a bit of confusion here. When the user injects a new key with > the same description and new passphrase, would that not replace the > existing user key with the old passphrase? Also, if I'm calling > lookup_user_key, where would the key_id come from for the old user key? > I suppose I can cache it.... Maybe I'm not quite understanding the exact > flow of how things you are suggesting.
If the DIMM is in the in the unlocked state the kernel should already have the old passphrase cached, right? Could we just have the kernel fail ->change_key() requests if the kernel does not already have a valid old passphrase? It does mean we can't support going from the locked state directly to changing the password, but I would expect requiring an initial unlock is fine. _______________________________________________ Linux-nvdimm mailing list [email protected] https://lists.01.org/mailman/listinfo/linux-nvdimm
