On Mon, Jul 2, 2018 at 9:58 PM, Elliott, Robert (Persistent Memory) <[email protected]> wrote: > >> > Since it contains a high-value password, I recommend zeroing >> > cmd->passphrase before calling kfree() so that data isn't seen >> > by a subsequent kmalloc() caller (and make sure the compiler >> > cannot optimize away the clearing code). >> > >> > Also, check if the ndctl() call chain makes any copies of cmd- >> > passphrase and ensure they are cleared. >> >> If an attacker can run arbitrary code in the kernel they can get the >> key from the ring directly, or turn on ACPI debug. A platform could >> arrange for the DIMMs to be unlocked pre-OS to minimize passphrase >> exposure, but once you need to unlock from the OS at runtime there is >> this exposure. Now, there may be ways we could protect the key the >> TPM >> to minimize exposure, but there would always be the in-flight risk, >> especially with ACPI debug. > > TCG Opal poses the same problems, discussed before in this thread: > http://lists.infradead.org/pipermail/linux-nvme/2016-May/004646.html > > Ultimately we might need to rely on code running in encrypted memory > (e.g., SGX) to unpack the password from TPM-based storage, wrap it with > a temporary session key (e.g., based on TCG PSK secure sessions, or > public/private keys), and only pass that non-reusable bundle through > the kernel. That'll require more complex devices, though.
Agreed. At least this implementation avoids sedutil and reuses the keyctl api directly. _______________________________________________ Linux-nvdimm mailing list [email protected] https://lists.01.org/mailman/listinfo/linux-nvdimm
