> > 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. _______________________________________________ Linux-nvdimm mailing list Linux-nvdimm@lists.01.org https://lists.01.org/mailman/listinfo/linux-nvdimm
