On Tue, Mar 26, 2019 at 10:06 AM Dave Jiang <[email protected]> wrote: > > Adding support to allow secure erase to happen when security state is not > enabled. Key data of 0's will be passed in.
That still sounds more like a feature than a fix, and if I'm looking closer than the fix is to make sure that all nvdimm_lookup_user_key() invocations always return data, at least for all the "current / old" passphrase cases. Because, afaics there's no way to unlock a DIMM if a platform implements a zero-key default. Also the current "freeze on no key" functionality will fail if the DIMM expects the zero-key. nvdimm_lookup_user_key(good_key_id, current_key) => user key payload nvdimm_lookup_user_key(bad_key_id) => zero key payload, but should fail if this was the key-id for the new-passphrase / key nvdimm_lookup_user_key(0) => zero key payload. This guarantees that zero-key semantic is uniform across all current / old-passphrase use cases. > Some other security commands already use zero keys. This is to unifiy > semantics cross commands with respect to using zero keys. We should say a bit why this is important and the knowledge that there are some platforms that default to a zero-key. This is the primary justification for the change. For a -rc change of this nature the status as a fix needs to be clear otherwise it will be deferred to v5.2. For example if I were Linus I would reject any patch that starts "Adding support" and not read the rest of the changelog at this stage of the development cycle. _______________________________________________ Linux-nvdimm mailing list [email protected] https://lists.01.org/mailman/listinfo/linux-nvdimm
