Multi-Key Total Memory Encryption (MKTME) [1] is feature of a memory controller that allows memory to be selectively encrypted with user-controlled key, in hardware, at a very low runtime cost. However, it is implemented using AES-XTS which encrypts each block with a key that is generated based on the physical address of the data being encrypted. This has nice security properties, making some replay and substitution attacks harder, but it means that encrypted data can not be naively relocated. Combined with persistent memory, MKTME allows data to be unlocked at the device (DIMM or namespace) level, but left encrypted until it actually needs to be used. However, if encrypted data were placed on a filesystem, it might be in its encrypted state for long periods of time and could not be moved by the filesystem during that time. The “easy” solution to this is to just require that the encryption key be present and programmed into the memory controller before data is moved. However, this means that filesystems would need to know when a given block has been encrypted and can not be moved. We would like to discuss an early proposal for the tooling, APIs and on-disk changes necessary to implement this feature and ensure we have not overlooked the interactions with complementary features like existing software-driven encryption (eCryptfs and fscrypt). 1. https://patchwork.kernel.org/cover/10592621/
