On Tue, Dec 4, 2018 at 11:19 AM Andy Lutomirski <luto@xxxxxxxxxx> wrote: > > On Mon, Dec 3, 2018 at 11:37 PM Alison Schofield > <alison.schofield@xxxxxxxxx> wrote: > > > Finally, If you're going to teach the kernel how to have some user > pages that aren't in the direct map, you've essentially done XPO, > which is nifty but expensive. And I think that doing this gets you > essentially all the benefit of MKTME for the non-pmem use case. Why > exactly would any software want to use anything other than a > CPU-managed key for anything other than pmem? > Let me say this less abstractly. Here's a somewhat concrete actual proposal. Make a new memfd_create() flag like MEMFD_ISOLATED. The semantics are that the underlying pages are made not-present in the direct map when they're allocated (which is hideously slow, but so be it), and that anything that tries to get_user_pages() the resulting pages fails. And then make sure we have all the required APIs so that QEMU can still map this stuff into a VM. If there is indeed a situation in which MKTME-ifying the memory adds some value, then we can consider doing that. And maybe we get fancy and encrypt this memory when it's swapped, but maybe we should just encrypt everything when it's swapped.
