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.
