On Fri, Jun 14, 2019 at 01:44:08PM +0200, Peter Zijlstra wrote: > On Wed, May 08, 2019 at 05:44:04PM +0300, Kirill A. Shutemov wrote: > > From: Alison Schofield <alison.schofield@xxxxxxxxx> > > > > MKTME architecture requires the KeyID to be placed in PTE bits 51:46. > > To create an encrypted VMA, place the KeyID in the upper bits of > > vm_page_prot that matches the position of those PTE bits. > > > > When the VMA is assigned a KeyID it is always considered a KeyID > > change. The VMA is either going from not encrypted to encrypted, > > or from encrypted with any KeyID to encrypted with any other KeyID. > > To make the change safely, remove the user pages held by the VMA > > and unlink the VMA's anonymous chain. > > This does not look like a transformation that preserves content; is > mprotect() still a suitable name? Data is not preserved across KeyID changes, by design. Background: We chose to implement encrypt_mprotect() as an extension to the legacy mprotect so that memory allocated in any method could be encrypted. ie. we didn't want to be tied to mmap. As an mprotect extension, encrypt_mprotect also supports the changing of access flags. The usage we suggest is: 1) alloc the memory w PROT_NONE to prevent any usage before encryption 2) use encrypt_mprotect() to add the key and change the access to PROT_WRITE|PROT_READ. 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. Back to your naming question: Since it is an mprotect extension, it seems we need to keep the mprotect in the name. Thanks for bringing it up. It would be good to hear more thoughts on this.
