On 2/13/19 12:21 PM, Dave Chinner wrote: > On Wed, Feb 13, 2019 at 07:51:12AM -0800, Dave Hansen wrote: >> On 2/12/19 7:31 PM, Dan Williams wrote: >>> Thanks, yes, fscrypt needs a closer look. As far I can see at a quick >>> glance fscrypt has the same physical block inputs for the encryption >>> algorithm as MKTME so it seems it could be crafted as a drop in >>> accelerator for fscrypt for pmem block devices. >> >> One bummer is that we have the platform tweak offsets to worry about. > > What's a "platform tweak offset"? AES-XTS uses a "tweak key" that is typically generated from the physical address of the data being encrypted. This mitigates block-relocation attacks. However, in a real server, the physical address of an NVDIMM might change due to a bunch of things, like a PCI card or memory getting added or removed. The platform tweak offsets allow the physical address that actually goes into generating the tweak key to be adjusted. This can keep the tweak key for a physical block constant even if the block moves around in the address space. >> As far as I know, those are opaque to software and practically prevent >> us from replicating the MKTME hardware's encryption/decryption in software. > > We're not trying to replicate the encryption in software, just use > the existing software to manage the keys that get fed to the > hardware so it can do the encrypt/decrypt operations as the data > passes through it. OK, managing the keys alone sounds sane. I really need to do some fscrypt homework to see how it manages keys.
