On Tue, Mar 26, 2019 at 10:06 AM Dave Jiang <dave.jiang(a)intel.com> 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.