On 6/14/19 11:46 AM, Alison Schofield wrote: > 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 ?
Well, it got to be plaintext because they wrote it to memory in plaintext in the first place, so it's kinda hard to disappoint them. :) IMNHO, the *vast* majority of cases, folks will allocate memory and then put a secret in it. They aren't going to *get* a secret in some mysterious fashion and then later decide they want to protect it. In other words, the inability to convert it is pretty academic and not worth the complexity.
