Loading...
1===============
2NVDIMM Security
3===============
4
51. Introduction
6---------------
7
8With the introduction of Intel Device Specific Methods (DSM) v1.8
9specification [1], security DSMs are introduced. The spec added the following
10security DSMs: "get security state", "set passphrase", "disable passphrase",
11"unlock unit", "freeze lock", "secure erase", and "overwrite". A security_ops
12data structure has been added to struct dimm in order to support the security
13operations and generic APIs are exposed to allow vendor neutral operations.
14
152. Sysfs Interface
16------------------
17The "security" sysfs attribute is provided in the nvdimm sysfs directory. For
18example:
19/sys/devices/LNXSYSTM:00/LNXSYBUS:00/ACPI0012:00/ndbus0/nmem0/security
20
21The "show" attribute of that attribute will display the security state for
22that DIMM. The following states are available: disabled, unlocked, locked,
23frozen, and overwrite. If security is not supported, the sysfs attribute
24will not be visible.
25
26The "store" attribute takes several commands when it is being written to
27in order to support some of the security functionalities:
28update <old_keyid> <new_keyid> - enable or update passphrase.
29disable <keyid> - disable enabled security and remove key.
30freeze - freeze changing of security states.
31erase <keyid> - delete existing user encryption key.
32overwrite <keyid> - wipe the entire nvdimm.
33master_update <keyid> <new_keyid> - enable or update master passphrase.
34master_erase <keyid> - delete existing user encryption key.
35
363. Key Management
37-----------------
38
39The key is associated to the payload by the DIMM id. For example:
40# cat /sys/devices/LNXSYSTM:00/LNXSYBUS:00/ACPI0012:00/ndbus0/nmem0/nfit/id
418089-a2-1740-00000133
42The DIMM id would be provided along with the key payload (passphrase) to
43the kernel.
44
45The security keys are managed on the basis of a single key per DIMM. The
46key "passphrase" is expected to be 32bytes long. This is similar to the ATA
47security specification [2]. A key is initially acquired via the request_key()
48kernel API call during nvdimm unlock. It is up to the user to make sure that
49all the keys are in the kernel user keyring for unlock.
50
51A nvdimm encrypted-key of format enc32 has the description format of:
52nvdimm:<bus-provider-specific-unique-id>
53
54See file ``Documentation/security/keys/trusted-encrypted.rst`` for creating
55encrypted-keys of enc32 format. TPM usage with a master trusted key is
56preferred for sealing the encrypted-keys.
57
584. Unlocking
59------------
60When the DIMMs are being enumerated by the kernel, the kernel will attempt to
61retrieve the key from the kernel user keyring. This is the only time
62a locked DIMM can be unlocked. Once unlocked, the DIMM will remain unlocked
63until reboot. Typically an entity (i.e. shell script) will inject all the
64relevant encrypted-keys into the kernel user keyring during the initramfs phase.
65This provides the unlock function access to all the related keys that contain
66the passphrase for the respective nvdimms. It is also recommended that the
67keys are injected before libnvdimm is loaded by modprobe.
68
695. Update
70---------
71When doing an update, it is expected that the existing key is removed from
72the kernel user keyring and reinjected as different (old) key. It's irrelevant
73what the key description is for the old key since we are only interested in the
74keyid when doing the update operation. It is also expected that the new key
75is injected with the description format described from earlier in this
76document. The update command written to the sysfs attribute will be with
77the format:
78update <old keyid> <new keyid>
79
80If there is no old keyid due to a security enabling, then a 0 should be
81passed in.
82
836. Freeze
84---------
85The freeze operation does not require any keys. The security config can be
86frozen by a user with root privilege.
87
887. Disable
89----------
90The security disable command format is:
91disable <keyid>
92
93An key with the current passphrase payload that is tied to the nvdimm should be
94in the kernel user keyring.
95
968. Secure Erase
97---------------
98The command format for doing a secure erase is:
99erase <keyid>
100
101An key with the current passphrase payload that is tied to the nvdimm should be
102in the kernel user keyring.
103
1049. Overwrite
105------------
106The command format for doing an overwrite is:
107overwrite <keyid>
108
109Overwrite can be done without a key if security is not enabled. A key serial
110of 0 can be passed in to indicate no key.
111
112The sysfs attribute "security" can be polled to wait on overwrite completion.
113Overwrite can last tens of minutes or more depending on nvdimm size.
114
115An encrypted-key with the current user passphrase that is tied to the nvdimm
116should be injected and its keyid should be passed in via sysfs.
117
11810. Master Update
119-----------------
120The command format for doing a master update is:
121update <old keyid> <new keyid>
122
123The operating mechanism for master update is identical to update except the
124master passphrase key is passed to the kernel. The master passphrase key
125is just another encrypted-key.
126
127This command is only available when security is disabled.
128
12911. Master Erase
130----------------
131The command format for doing a master erase is:
132master_erase <current keyid>
133
134This command has the same operating mechanism as erase except the master
135passphrase key is passed to the kernel. The master passphrase key is just
136another encrypted-key.
137
138This command is only available when the master security is enabled, indicated
139by the extended security status.
140
141[1]: https://pmem.io/documents/NVDIMM_DSM_Interface-V1.8.pdf
142
143[2]: http://www.t13.org/documents/UploadedDocuments/docs2006/e05179r4-ACS-SecurityClarifications.pdf
1===============
2NVDIMM Security
3===============
4
51. Introduction
6---------------
7
8With the introduction of Intel Device Specific Methods (DSM) v1.8
9specification [1], security DSMs are introduced. The spec added the following
10security DSMs: "get security state", "set passphrase", "disable passphrase",
11"unlock unit", "freeze lock", "secure erase", and "overwrite". A security_ops
12data structure has been added to struct dimm in order to support the security
13operations and generic APIs are exposed to allow vendor neutral operations.
14
152. Sysfs Interface
16------------------
17The "security" sysfs attribute is provided in the nvdimm sysfs directory. For
18example:
19/sys/devices/LNXSYSTM:00/LNXSYBUS:00/ACPI0012:00/ndbus0/nmem0/security
20
21The "show" attribute of that attribute will display the security state for
22that DIMM. The following states are available: disabled, unlocked, locked,
23frozen, and overwrite. If security is not supported, the sysfs attribute
24will not be visible.
25
26The "store" attribute takes several commands when it is being written to
27in order to support some of the security functionalities:
28update <old_keyid> <new_keyid> - enable or update passphrase.
29disable <keyid> - disable enabled security and remove key.
30freeze - freeze changing of security states.
31erase <keyid> - delete existing user encryption key.
32overwrite <keyid> - wipe the entire nvdimm.
33master_update <keyid> <new_keyid> - enable or update master passphrase.
34master_erase <keyid> - delete existing user encryption key.
35
363. Key Management
37-----------------
38
39The key is associated to the payload by the DIMM id. For example:
40# cat /sys/devices/LNXSYSTM:00/LNXSYBUS:00/ACPI0012:00/ndbus0/nmem0/nfit/id
418089-a2-1740-00000133
42The DIMM id would be provided along with the key payload (passphrase) to
43the kernel.
44
45The security keys are managed on the basis of a single key per DIMM. The
46key "passphrase" is expected to be 32bytes long. This is similar to the ATA
47security specification [2]. A key is initially acquired via the request_key()
48kernel API call during nvdimm unlock. It is up to the user to make sure that
49all the keys are in the kernel user keyring for unlock.
50
51A nvdimm encrypted-key of format enc32 has the description format of:
52nvdimm:<bus-provider-specific-unique-id>
53
54See file ``Documentation/security/keys/trusted-encrypted.rst`` for creating
55encrypted-keys of enc32 format. TPM usage with a master trusted key is
56preferred for sealing the encrypted-keys.
57
584. Unlocking
59------------
60When the DIMMs are being enumerated by the kernel, the kernel will attempt to
61retrieve the key from the kernel user keyring. This is the only time
62a locked DIMM can be unlocked. Once unlocked, the DIMM will remain unlocked
63until reboot. Typically an entity (i.e. shell script) will inject all the
64relevant encrypted-keys into the kernel user keyring during the initramfs phase.
65This provides the unlock function access to all the related keys that contain
66the passphrase for the respective nvdimms. It is also recommended that the
67keys are injected before libnvdimm is loaded by modprobe.
68
695. Update
70---------
71When doing an update, it is expected that the existing key is removed from
72the kernel user keyring and reinjected as different (old) key. It's irrelevant
73what the key description is for the old key since we are only interested in the
74keyid when doing the update operation. It is also expected that the new key
75is injected with the description format described from earlier in this
76document. The update command written to the sysfs attribute will be with
77the format:
78update <old keyid> <new keyid>
79
80If there is no old keyid due to a security enabling, then a 0 should be
81passed in.
82
836. Freeze
84---------
85The freeze operation does not require any keys. The security config can be
86frozen by a user with root privilege.
87
887. Disable
89----------
90The security disable command format is:
91disable <keyid>
92
93An key with the current passphrase payload that is tied to the nvdimm should be
94in the kernel user keyring.
95
968. Secure Erase
97---------------
98The command format for doing a secure erase is:
99erase <keyid>
100
101An key with the current passphrase payload that is tied to the nvdimm should be
102in the kernel user keyring.
103
1049. Overwrite
105------------
106The command format for doing an overwrite is:
107overwrite <keyid>
108
109Overwrite can be done without a key if security is not enabled. A key serial
110of 0 can be passed in to indicate no key.
111
112The sysfs attribute "security" can be polled to wait on overwrite completion.
113Overwrite can last tens of minutes or more depending on nvdimm size.
114
115An encrypted-key with the current user passphrase that is tied to the nvdimm
116should be injected and its keyid should be passed in via sysfs.
117
11810. Master Update
119-----------------
120The command format for doing a master update is:
121update <old keyid> <new keyid>
122
123The operating mechanism for master update is identical to update except the
124master passphrase key is passed to the kernel. The master passphrase key
125is just another encrypted-key.
126
127This command is only available when security is disabled.
128
12911. Master Erase
130----------------
131The command format for doing a master erase is:
132master_erase <current keyid>
133
134This command has the same operating mechanism as erase except the master
135passphrase key is passed to the kernel. The master passphrase key is just
136another encrypted-key.
137
138This command is only available when the master security is enabled, indicated
139by the extended security status.
140
141[1]: https://pmem.io/documents/NVDIMM_DSM_Interface-V1.8.pdf
142
143[2]: http://www.t13.org/documents/UploadedDocuments/docs2006/e05179r4-ACS-SecurityClarifications.pdf