On Wed, May 8, 2019 at 7:44 AM Kirill A. Shutemov <kirill.shutemov@xxxxxxxxxxxxxxx> wrote: > > From: Alison Schofield <alison.schofield@xxxxxxxxx> > > Implement memory encryption for MKTME (Multi-Key Total Memory > Encryption) with a new system call that is an extension of the > legacy mprotect() system call. > > In encrypt_mprotect the caller must pass a handle to a previously > allocated and programmed MKTME encryption key. The key can be > obtained through the kernel key service type "mktme". The caller > must have KEY_NEED_VIEW permission on the key. > > MKTME places an additional restriction on the protected data: > The length of the data must be page aligned. This is in addition > to the existing mprotect restriction that the addr must be page > aligned. I still find it bizarre that this is conflated with mprotect(). I also remain entirely unconvinced that MKTME on anonymous memory is useful in the long run. There will inevitably be all kinds of fancy new CPU features that make the underlying MKTME mechanisms much more useful. For example, some way to bind a key to a VM, or a way to *sanely* encrypt persistent memory. By making this thing a syscall that does more than just MKTME, you're adding combinatorial complexity (you forget pkey!) and you're tying other functionality (change of protection) to this likely-to-be-deprecated interface. This is part of why I much prefer the idea of making this style of MKTME a driver or some other non-intrusive interface. Then, once everyone gets tired of it, the driver can just get turned off with no side effects. --Andy
