diff options
author | Dan Williams <dan.j.williams@intel.com> | 2019-08-26 17:54:54 -0700 |
---|---|---|
committer | Dan Williams <dan.j.williams@intel.com> | 2019-08-29 13:49:13 -0700 |
commit | d78c620a2e824d7b01a6e991208a8aa2c938cabe (patch) | |
tree | c37be9e345e45b7370fc4b0287472a478b790b7d /tools/firewire | |
parent | 2b90cb223320a93b1be6c2616efe6f9ff14d8b28 (diff) | |
download | linux-stable-d78c620a2e824d7b01a6e991208a8aa2c938cabe.tar.gz linux-stable-d78c620a2e824d7b01a6e991208a8aa2c938cabe.tar.bz2 linux-stable-d78c620a2e824d7b01a6e991208a8aa2c938cabe.zip |
libnvdimm/security: Introduce a 'frozen' attribute
In the process of debugging a system with an NVDIMM that was failing to
unlock it was found that the kernel is reporting 'locked' while the DIMM
security interface is 'frozen'. Unfortunately the security state is
tracked internally as an enum which prevents it from communicating the
difference between 'locked' and 'locked + frozen'. It follows that the
enum also prevents the kernel from communicating 'unlocked + frozen'
which would be useful for debugging why security operations like 'change
passphrase' are disabled.
Ditch the security state enum for a set of flags and introduce a new
sysfs attribute explicitly for the 'frozen' state. The regression risk
is low because the 'frozen' state was already blocked behind the
'locked' state, but will need to revisit if there were cases where
applications need 'frozen' to show up in the primary 'security'
attribute. The expectation is that communicating 'frozen' is mostly a
helper for debug and status monitoring.
Reviewed-by: Dave Jiang <dave.jiang@intel.com>
Reported-by: Jeff Moyer <jmoyer@redhat.com>
Reviewed-by: Jeff Moyer <jmoyer@redhat.com>
Link: https://lore.kernel.org/r/156686729474.184120.5835135644278860826.stgit@dwillia2-desk3.amr.corp.intel.com
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
Diffstat (limited to 'tools/firewire')
0 files changed, 0 insertions, 0 deletions