libnvdimm/security: Add documentation for nvdimm security support
Add theory of operation for the security support that's going into libnvdimm. Signed-off-by: Dave Jiang <dave.jiang@intel.com> Reviewed-by: Jing Lin <jing.lin@intel.com> Signed-off-by: Dan Williams <dan.j.williams@intel.com>
This commit is contained in:
Dave Jiang
Dan Williams
parent
ecaa4a97b3
commit
1f4883f300
|
|
@ -0,0 +1,141 @@
|
|||
NVDIMM SECURITY
|
||||
===============
|
||||
|
||||
1. Introduction
|
||||
---------------
|
||||
|
||||
With the introduction of Intel Device Specific Methods (DSM) v1.8
|
||||
specification [1], security DSMs are introduced. The spec added the following
|
||||
security DSMs: "get security state", "set passphrase", "disable passphrase",
|
||||
"unlock unit", "freeze lock", "secure erase", and "overwrite". A security_ops
|
||||
data structure has been added to struct dimm in order to support the security
|
||||
operations and generic APIs are exposed to allow vendor neutral operations.
|
||||
|
||||
2. Sysfs Interface
|
||||
------------------
|
||||
The "security" sysfs attribute is provided in the nvdimm sysfs directory. For
|
||||
example:
|
||||
/sys/devices/LNXSYSTM:00/LNXSYBUS:00/ACPI0012:00/ndbus0/nmem0/security
|
||||
|
||||
The "show" attribute of that attribute will display the security state for
|
||||
that DIMM. The following states are available: disabled, unlocked, locked,
|
||||
frozen, and overwrite. If security is not supported, the sysfs attribute
|
||||
will not be visible.
|
||||
|
||||
The "store" attribute takes several commands when it is being written to
|
||||
in order to support some of the security functionalities:
|
||||
update <old_keyid> <new_keyid> - enable or update passphrase.
|
||||
disable <keyid> - disable enabled security and remove key.
|
||||
freeze - freeze changing of security states.
|
||||
erase <keyid> - delete existing user encryption key.
|
||||
overwrite <keyid> - wipe the entire nvdimm.
|
||||
master_update <keyid> <new_keyid> - enable or update master passphrase.
|
||||
master_erase <keyid> - delete existing user encryption key.
|
||||
|
||||
3. Key Management
|
||||
-----------------
|
||||
|
||||
The key is associated to the payload by the DIMM id. For example:
|
||||
# cat /sys/devices/LNXSYSTM:00/LNXSYBUS:00/ACPI0012:00/ndbus0/nmem0/nfit/id
|
||||
8089-a2-1740-00000133
|
||||
The DIMM id would be provided along with the key payload (passphrase) to
|
||||
the kernel.
|
||||
|
||||
The security keys are managed on the basis of a single key per DIMM. The
|
||||
key "passphrase" is expected to be 32bytes long. This is similar to the ATA
|
||||
security specification [2]. A key is initially acquired via the request_key()
|
||||
kernel API call during nvdimm unlock. It is up to the user to make sure that
|
||||
all the keys are in the kernel user keyring for unlock.
|
||||
|
||||
A nvdimm encrypted-key of format enc32 has the description format of:
|
||||
nvdimm:<bus-provider-specific-unique-id>
|
||||
|
||||
See file ``Documentation/security/keys/trusted-encrypted.rst`` for creating
|
||||
encrypted-keys of enc32 format. TPM usage with a master trusted key is
|
||||
preferred for sealing the encrypted-keys.
|
||||
|
||||
4. Unlocking
|
||||
------------
|
||||
When the DIMMs are being enumerated by the kernel, the kernel will attempt to
|
||||
retrieve the key from the kernel user keyring. This is the only time
|
||||
a locked DIMM can be unlocked. Once unlocked, the DIMM will remain unlocked
|
||||
until reboot. Typically an entity (i.e. shell script) will inject all the
|
||||
relevant encrypted-keys into the kernel user keyring during the initramfs phase.
|
||||
This provides the unlock function access to all the related keys that contain
|
||||
the passphrase for the respective nvdimms. It is also recommended that the
|
||||
keys are injected before libnvdimm is loaded by modprobe.
|
||||
|
||||
5. Update
|
||||
---------
|
||||
When doing an update, it is expected that the existing key is removed from
|
||||
the kernel user keyring and reinjected as different (old) key. It's irrelevant
|
||||
what the key description is for the old key since we are only interested in the
|
||||
keyid when doing the update operation. It is also expected that the new key
|
||||
is injected with the description format described from earlier in this
|
||||
document. The update command written to the sysfs attribute will be with
|
||||
the format:
|
||||
update <old keyid> <new keyid>
|
||||
|
||||
If there is no old keyid due to a security enabling, then a 0 should be
|
||||
passed in.
|
||||
|
||||
6. Freeze
|
||||
---------
|
||||
The freeze operation does not require any keys. The security config can be
|
||||
frozen by a user with root privelege.
|
||||
|
||||
7. Disable
|
||||
----------
|
||||
The security disable command format is:
|
||||
disable <keyid>
|
||||
|
||||
An key with the current passphrase payload that is tied to the nvdimm should be
|
||||
in the kernel user keyring.
|
||||
|
||||
8. Secure Erase
|
||||
---------------
|
||||
The command format for doing a secure erase is:
|
||||
erase <keyid>
|
||||
|
||||
An key with the current passphrase payload that is tied to the nvdimm should be
|
||||
in the kernel user keyring.
|
||||
|
||||
9. Overwrite
|
||||
------------
|
||||
The command format for doing an overwrite is:
|
||||
overwrite <keyid>
|
||||
|
||||
Overwrite can be done without a key if security is not enabled. A key serial
|
||||
of 0 can be passed in to indicate no key.
|
||||
|
||||
The sysfs attribute "security" can be polled to wait on overwrite completion.
|
||||
Overwrite can last tens of minutes or more depending on nvdimm size.
|
||||
|
||||
An encrypted-key with the current user passphrase that is tied to the nvdimm
|
||||
should be injected and its keyid should be passed in via sysfs.
|
||||
|
||||
10. Master Update
|
||||
-----------------
|
||||
The command format for doing a master update is:
|
||||
update <old keyid> <new keyid>
|
||||
|
||||
The operating mechanism for master update is identical to update except the
|
||||
master passphrase key is passed to the kernel. The master passphrase key
|
||||
is just another encrypted-key.
|
||||
|
||||
This command is only available when security is disabled.
|
||||
|
||||
11. Master Erase
|
||||
----------------
|
||||
The command format for doing a master erase is:
|
||||
master_erase <current keyid>
|
||||
|
||||
This command has the same operating mechanism as erase except the master
|
||||
passphrase key is passed to the kernel. The master passphrase key is just
|
||||
another encrypted-key.
|
||||
|
||||
This command is only available when the master security is enabled, indicated
|
||||
by the extended security status.
|
||||
|
||||
[1]: http://pmem.io/documents/NVDIMM_DSM_Interface-V1.8.pdf
|
||||
[2]: http://www.t13.org/documents/UploadedDocuments/docs2006/e05179r4-ACS-SecurityClarifications.pdf
|
||||
Loading…
Reference in New Issue