Messages in this thread | | | Date | Fri, 14 Jun 2019 11:46:02 -0700 | From | Alison Schofield <> | Subject | Re: [PATCH, RFC 44/62] x86/mm: Set KeyIDs in encrypted VMAs for MKTME |
| |
On Fri, Jun 14, 2019 at 11:26:10AM -0700, Dave Hansen wrote: > On 6/14/19 10:33 AM, Alison Schofield wrote: > > Preserving the data across encryption key changes has not > > been a requirement. I'm not clear if it was ever considered > > and rejected. I believe that copying in order to preserve > > the data was never considered. > > We could preserve the data pretty easily. It's just annoying, though. > Right now, our only KeyID conversions happen in the page allocator. If > we were to convert in-place, we'd need something along the lines of: > > 1. Allocate a scratch page > 2. Unmap target page, or at least make it entirely read-only > 3. Copy plaintext into scratch page > 4. Do cache KeyID conversion of page being converted: > Flush caches, change page_ext metadata > 5. Copy plaintext back into target page from scratch area > 6. Re-establish PTEs with new KeyID
Seems like the 'Copy plaintext' steps might disappoint the user, as much as the 'we don't preserve your data' design. Would users be happy w the plain text steps ? Alison
> > #2 is *really* hard. It's similar to the problems that the poor > filesystem guys are having with RDMA these days when RDMA is doing writes. > > What we have here (destroying existing data) is certainly the _simplest_ > semantic. We can certainly give it a different name, or even non-PROT_* > semantics where it shares none of mprotect()'s functionality. > > Doesn't really matter to me at all.
| |