lkml.org 
[lkml]   [2019]   [Jun]   [14]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: [PATCH, RFC 44/62] x86/mm: Set KeyIDs in encrypted VMAs for MKTME
From
Date
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

#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.

\
 
 \ /
  Last update: 2019-06-14 20:28    [W:0.096 / U:9.788 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site