From: "Sakkinen, Jarkko" <jarkko.sakkinen@intel.com>
To: "tglx@linutronix.de" <tglx@linutronix.de>,
"Schofield, Alison" <alison.schofield@intel.com>,
"dhowells@redhat.com" <dhowells@redhat.com>
Cc: "kirill.shutemov@linux.intel.com"
<kirill.shutemov@linux.intel.com>,
"peterz@infradead.org" <peterz@infradead.org>,
"jmorris@namei.org" <jmorris@namei.org>,
"Huang, Kai" <kai.huang@intel.com>,
"keyrings@vger.kernel.org" <keyrings@vger.kernel.org>,
"linux-mm@kvack.org" <linux-mm@kvack.org>,
"linux-security-module@vger.kernel.org"
<linux-security-module@vger.kernel.org>,
"Williams, Dan J" <dan.j.williams@intel.com>,
"x86@kernel.org" <x86@kernel.org>,
"hpa@zytor.com" <hpa@zytor.com>,
"mingo@redhat.com" <mingo@redhat.com>,
"luto@kernel.org" <luto@kernel.org>,
"bp@alien8.de" <bp@alien8.de>,
"Hansen, Dave" <dave.hansen@intel.com>,
"Nakajima, Jun" <jun.nakajima@intel.com>
Subject: Re: [RFC v2 05/13] x86/mm: Set KeyIDs in encrypted VMAs
Date: Thu, 6 Dec 2018 08:37:15 +0000 [thread overview]
Message-ID: <fedb2e7fa0ffb9ee80ca2e8228f2d674781babbd.camel@intel.com> (raw)
In-Reply-To: <f0ff967e2015a9dffceef22ac52ecd736a1ddb7e.1543903910.git.alison.schofield@intel.com>
On Mon, 2018-12-03 at 23:39 -0800, Alison Schofield wrote:
> 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.
>
> Change-Id: I676056525c49c8803898315a10b196ef5a5c5415
Remove.
> Signed-off-by: Alison Schofield <alison.schofield@intel.com>
> Signed-off-by: Kirill A. Shutemov <kirill.shutemov@linux.intel.com>
> ---
> arch/x86/include/asm/mktme.h | 4 ++++
> arch/x86/mm/mktme.c | 26 ++++++++++++++++++++++++++
> include/linux/mm.h | 6 ++++++
> 3 files changed, 36 insertions(+)
>
> diff --git a/arch/x86/include/asm/mktme.h b/arch/x86/include/asm/mktme.h
> index dbb49909d665..de3e529f3ab0 100644
> --- a/arch/x86/include/asm/mktme.h
> +++ b/arch/x86/include/asm/mktme.h
> @@ -24,6 +24,10 @@ extern int mktme_map_keyid_from_key(void *key);
> extern void *mktme_map_key_from_keyid(int keyid);
> extern int mktme_map_get_free_keyid(void);
>
> +/* Set the encryption keyid bits in a VMA */
> +extern void mprotect_set_encrypt(struct vm_area_struct *vma, int newkeyid,
> + unsigned long start, unsigned long end);
> +
> DECLARE_STATIC_KEY_FALSE(mktme_enabled_key);
> static inline bool mktme_enabled(void)
> {
> diff --git a/arch/x86/mm/mktme.c b/arch/x86/mm/mktme.c
> index 34224d4e3f45..e3fdf7b48173 100644
> --- a/arch/x86/mm/mktme.c
> +++ b/arch/x86/mm/mktme.c
> @@ -1,5 +1,6 @@
> #include <linux/mm.h>
> #include <linux/highmem.h>
> +#include <linux/rmap.h>
> #include <asm/mktme.h>
> #include <asm/set_memory.h>
>
> @@ -131,6 +132,31 @@ int mktme_map_get_free_keyid(void)
> return 0;
> }
>
> +/* Set the encryption keyid bits in a VMA */
Maybe proper kdoc?
> +void mprotect_set_encrypt(struct vm_area_struct *vma, int newkeyid,
> + unsigned long start, unsigned long end)
> +{
> + int oldkeyid = vma_keyid(vma);
> + pgprotval_t newprot;
> +
> + /* Unmap pages with old KeyID if there's any. */
> + zap_page_range(vma, start, end - start);
> +
> + if (oldkeyid == newkeyid)
> + return;
> +
> + newprot = pgprot_val(vma->vm_page_prot);
> + newprot &= ~mktme_keyid_mask;
> + newprot |= (unsigned long)newkeyid << mktme_keyid_shift;
> + vma->vm_page_prot = __pgprot(newprot);
> +
> + /*
No empty comment line.
> + * The VMA doesn't have any inherited pages.
> + * Start anon VMA tree from scratch.
> + */
> +}
> +
> /* Prepare page to be used for encryption. Called from page allocator. */
> void __prep_encrypted_page(struct page *page, int order, int keyid, bool
> zero)
> {
> diff --git a/include/linux/mm.h b/include/linux/mm.h
> index 1309761bb6d0..e2d87e92ca74 100644
> --- a/include/linux/mm.h
> +++ b/include/linux/mm.h
> @@ -2806,5 +2806,11 @@ void __init setup_nr_node_ids(void);
> static inline void setup_nr_node_ids(void) {}
> #endif
>
> +#ifndef CONFIG_X86_INTEL_MKTME
> +static inline void mprotect_set_encrypt(struct vm_area_struct *vma,
> + int newkeyid,
> + unsigned long start,
> + unsigned long end) {}
Add a new line and
{
}
> +#endif /* CONFIG_X86_INTEL_MKTME */
> #endif /* __KERNEL__ */
> #endif /* _LINUX_MM_H */
/Jarkko
next prev parent reply other threads:[~2018-12-06 8:37 UTC|newest]
Thread overview: 91+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-12-04 7:39 [RFC v2 00/13] Multi-Key Total Memory Encryption API (MKTME) Alison Schofield
2018-12-04 7:39 ` [RFC v2 01/13] x86/mktme: Document the MKTME APIs Alison Schofield
2018-12-05 18:11 ` Andy Lutomirski
2018-12-05 19:22 ` Alison Schofield
2018-12-05 23:35 ` Andy Lutomirski
2018-12-06 8:04 ` Sakkinen, Jarkko
2018-12-04 7:39 ` [RFC v2 02/13] mm: Generalize the mprotect implementation to support extensions Alison Schofield
2018-12-06 8:08 ` Sakkinen, Jarkko
2018-12-04 7:39 ` [RFC v2 03/13] syscall/x86: Wire up a new system call for memory encryption keys Alison Schofield
2018-12-04 7:39 ` [RFC v2 04/13] x86/mm: Add helper functions for MKTME " Alison Schofield
2018-12-04 9:14 ` Peter Zijlstra
2018-12-05 5:49 ` Alison Schofield
2018-12-04 15:35 ` Andy Lutomirski
2018-12-05 5:52 ` Alison Schofield
2018-12-06 8:31 ` Sakkinen, Jarkko
2018-12-04 7:39 ` [RFC v2 05/13] x86/mm: Set KeyIDs in encrypted VMAs Alison Schofield
2018-12-06 8:37 ` Sakkinen, Jarkko [this message]
2018-12-04 7:39 ` [RFC v2 06/13] mm: Add the encrypt_mprotect() system call Alison Schofield
2018-12-06 8:38 ` Sakkinen, Jarkko
2018-12-04 7:39 ` [RFC v2 07/13] x86/mm: Add helpers for reference counting encrypted VMAs Alison Schofield
2018-12-04 8:58 ` Peter Zijlstra
2018-12-05 5:28 ` Alison Schofield
2018-12-04 7:39 ` [RFC v2 08/13] mm: Use reference counting for " Alison Schofield
2018-12-04 7:39 ` [RFC v2 09/13] mm: Restrict memory encryption to anonymous VMA's Alison Schofield
2018-12-04 9:10 ` Peter Zijlstra
2018-12-05 5:30 ` Alison Schofield
2018-12-05 9:07 ` Peter Zijlstra
2018-12-04 7:39 ` [RFC v2 10/13] keys/mktme: Add the MKTME Key Service type for memory encryption Alison Schofield
2018-12-06 8:51 ` Sakkinen, Jarkko
2018-12-06 8:54 ` Sakkinen, Jarkko
2018-12-06 15:11 ` Dave Hansen
2018-12-06 22:56 ` Sakkinen, Jarkko
2018-12-04 7:39 ` [RFC v2 11/13] keys/mktme: Program memory encryption keys on a system wide basis Alison Schofield
2018-12-04 9:21 ` Peter Zijlstra
2018-12-04 9:50 ` Kirill A. Shutemov
2018-12-05 5:44 ` Alison Schofield
2018-12-05 5:43 ` Alison Schofield
2018-12-05 9:10 ` Peter Zijlstra
2018-12-05 17:26 ` Alison Schofield
2018-12-04 7:39 ` [RFC v2 12/13] keys/mktme: Save MKTME data if kernel cmdline parameter allows Alison Schofield
2018-12-04 9:22 ` Peter Zijlstra
2018-12-07 2:14 ` Huang, Kai
2018-12-07 3:42 ` Alison Schofield
2018-12-07 6:39 ` Jarkko Sakkinen
2018-12-07 6:45 ` Jarkko Sakkinen
2018-12-07 11:47 ` Kirill A. Shutemov
2018-12-04 7:40 ` [RFC v2 13/13] keys/mktme: Support CPU Hotplug for MKTME keys Alison Schofield
2018-12-04 9:28 ` Peter Zijlstra
2018-12-05 5:32 ` Alison Schofield
2018-12-04 9:31 ` Peter Zijlstra
2018-12-05 5:36 ` Alison Schofield
2018-12-04 9:25 ` [RFC v2 00/13] Multi-Key Total Memory Encryption API (MKTME) Peter Zijlstra
2018-12-04 9:46 ` Kirill A. Shutemov
2018-12-05 20:32 ` Sakkinen, Jarkko
2018-12-06 11:22 ` Kirill A. Shutemov
2018-12-06 14:59 ` Dave Hansen
2018-12-07 10:12 ` Huang, Kai
2018-12-06 21:23 ` Sakkinen, Jarkko
2018-12-07 11:54 ` Kirill A. Shutemov
2018-12-04 19:19 ` Andy Lutomirski
2018-12-04 20:00 ` Andy Lutomirski
2018-12-04 20:32 ` Dave Hansen
2018-12-05 22:19 ` Sakkinen, Jarkko
2018-12-07 2:05 ` Huang, Kai
2018-12-07 6:48 ` Jarkko Sakkinen
2018-12-07 11:57 ` Kirill A. Shutemov
2018-12-07 21:59 ` Sakkinen, Jarkko
2018-12-07 23:45 ` Sakkinen, Jarkko
2018-12-07 23:48 ` Andy Lutomirski
2018-12-08 1:33 ` Huang, Kai
2018-12-08 3:53 ` Sakkinen, Jarkko
2018-12-12 15:31 ` Sakkinen, Jarkko
2018-12-12 16:29 ` Andy Lutomirski
2018-12-12 16:43 ` Sakkinen, Jarkko
2018-12-12 23:27 ` Huang, Kai
2018-12-13 5:49 ` Sakkinen, Jarkko
2018-12-13 5:52 ` Sakkinen, Jarkko
2018-12-12 23:24 ` Huang, Kai
2018-12-07 23:35 ` Eric Rannaud
2018-12-05 23:49 ` Dave Hansen
2018-12-06 1:09 ` Andy Lutomirski
2018-12-06 1:25 ` Dan Williams
2018-12-06 15:39 ` Dave Hansen
2018-12-06 19:10 ` Andy Lutomirski
2018-12-06 19:31 ` Dave Hansen
2018-12-07 1:55 ` Huang, Kai
2018-12-07 4:23 ` Dave Hansen
2018-12-07 23:53 ` Andy Lutomirski
2018-12-08 1:11 ` Dave Hansen
2018-12-08 2:07 ` Huang, Kai
2018-12-05 20:30 ` Sakkinen, Jarkko
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=fedb2e7fa0ffb9ee80ca2e8228f2d674781babbd.camel@intel.com \
--to=jarkko.sakkinen@intel.com \
--cc=alison.schofield@intel.com \
--cc=bp@alien8.de \
--cc=dan.j.williams@intel.com \
--cc=dave.hansen@intel.com \
--cc=dhowells@redhat.com \
--cc=hpa@zytor.com \
--cc=jmorris@namei.org \
--cc=jun.nakajima@intel.com \
--cc=kai.huang@intel.com \
--cc=keyrings@vger.kernel.org \
--cc=kirill.shutemov@linux.intel.com \
--cc=linux-mm@kvack.org \
--cc=linux-security-module@vger.kernel.org \
--cc=luto@kernel.org \
--cc=mingo@redhat.com \
--cc=peterz@infradead.org \
--cc=tglx@linutronix.de \
--cc=x86@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).