From mboxrd@z Thu Jan 1 00:00:00 1970 From: Peter Zijlstra Date: Fri, 14 Jun 2019 11:44:08 +0000 Subject: Re: [PATCH, RFC 44/62] x86/mm: Set KeyIDs in encrypted VMAs for MKTME Message-Id: <20190614114408.GD3436@hirez.programming.kicks-ass.net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit List-Id: References: <20190508144422.13171-1-kirill.shutemov@linux.intel.com> <20190508144422.13171-45-kirill.shutemov@linux.intel.com> In-Reply-To: <20190508144422.13171-45-kirill.shutemov@linux.intel.com> To: "Kirill A. Shutemov" Cc: Andrew Morton , x86@kernel.org, Thomas Gleixner , Ingo Molnar , "H. Peter Anvin" , Borislav Petkov , Andy Lutomirski , David Howells , Kees Cook , Dave Hansen , Kai Huang , Jacob Pan , Alison Schofield , linux-mm@kvack.org, kvm@vger.kernel.org, keyrings@vger.kernel.org, linux-kernel@vger.kernel.org On Wed, May 08, 2019 at 05:44:04PM +0300, Kirill A. Shutemov wrote: > From: Alison Schofield > > 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?