From: "Kirill A. Shutemov" <kirill.shutemov@linux.intel.com>
To: Ingo Molnar <mingo@redhat.com>,
x86@kernel.org, Thomas Gleixner <tglx@linutronix.de>,
"H. Peter Anvin" <hpa@zytor.com>,
Tom Lendacky <thomas.lendacky@amd.com>
Cc: Dave Hansen <dave.hansen@intel.com>,
Kai Huang <kai.huang@linux.intel.com>,
linux-kernel@vger.kernel.org, linux-mm@kvack.org,
"Kirill A. Shutemov" <kirill.shutemov@linux.intel.com>
Subject: [RFC, PATCH 18/22] x86/mm: Handle allocation of encrypted pages
Date: Mon, 5 Mar 2018 19:26:06 +0300 [thread overview]
Message-ID: <20180305162610.37510-19-kirill.shutemov@linux.intel.com> (raw)
In-Reply-To: <20180305162610.37510-1-kirill.shutemov@linux.intel.com>
The hardware/CPU does not enforce coherency between mappings of the
same physical page with different KeyIDs or encrypt ion keys.
We are responsible for cache management.
We have to flush cache on allocation and freeing of encrypted page.
Failing to do this may lead to data corruption.
Zeroing of encrypted page has to be done with correct KeyID. In normal
situation kmap() takes care of creating temporary mapping for the page.
But during allocaiton path page doesn't have page->mapping set.
kmap_atomic_keyid() would map the page with the specified KeyID.
For now it's dummy implementation that would be replaced later.
Signed-off-by: Kirill A. Shutemov <kirill.shutemov@linux.intel.com>
---
arch/x86/include/asm/mktme.h | 3 +++
arch/x86/include/asm/page.h | 13 +++++++++++--
arch/x86/mm/mktme.c | 38 ++++++++++++++++++++++++++++++++++++++
3 files changed, 52 insertions(+), 2 deletions(-)
diff --git a/arch/x86/include/asm/mktme.h b/arch/x86/include/asm/mktme.h
index 08f613953207..c8f41837351a 100644
--- a/arch/x86/include/asm/mktme.h
+++ b/arch/x86/include/asm/mktme.h
@@ -5,6 +5,9 @@
struct vm_area_struct;
+struct page *__alloc_zeroed_encrypted_user_highpage(gfp_t gfp,
+ struct vm_area_struct *vma, unsigned long vaddr);
+
#ifdef CONFIG_X86_INTEL_MKTME
extern phys_addr_t mktme_keyid_mask;
extern int mktme_nr_keyids;
diff --git a/arch/x86/include/asm/page.h b/arch/x86/include/asm/page.h
index 7555b48803a8..8f808723f676 100644
--- a/arch/x86/include/asm/page.h
+++ b/arch/x86/include/asm/page.h
@@ -19,6 +19,7 @@
struct page;
#include <linux/range.h>
+#include <asm/mktme.h>
extern struct range pfn_mapped[];
extern int nr_pfn_mapped;
@@ -34,9 +35,17 @@ static inline void copy_user_page(void *to, void *from, unsigned long vaddr,
copy_page(to, from);
}
-#define __alloc_zeroed_user_highpage(movableflags, vma, vaddr) \
- alloc_page_vma(GFP_HIGHUSER | __GFP_ZERO | movableflags, vma, vaddr)
#define __HAVE_ARCH_ALLOC_ZEROED_USER_HIGHPAGE
+#define __alloc_zeroed_user_highpage(movableflags, vma, vaddr) \
+({ \
+ struct page *page; \
+ gfp_t gfp = movableflags | GFP_HIGHUSER; \
+ if (vma_is_encrypted(vma)) \
+ page = __alloc_zeroed_encrypted_user_highpage(gfp, vma, vaddr); \
+ else \
+ page = alloc_page_vma(gfp | __GFP_ZERO, vma, vaddr); \
+ page; \
+})
#ifndef __pa
#define __pa(x) __phys_addr((unsigned long)(x))
diff --git a/arch/x86/mm/mktme.c b/arch/x86/mm/mktme.c
index 3b2f28a21d99..1129ad25b22a 100644
--- a/arch/x86/mm/mktme.c
+++ b/arch/x86/mm/mktme.c
@@ -1,10 +1,17 @@
#include <linux/mm.h>
+#include <linux/highmem.h>
#include <asm/mktme.h>
phys_addr_t mktme_keyid_mask;
int mktme_nr_keyids;
int mktme_keyid_shift;
+void *kmap_atomic_keyid(struct page *page, int keyid)
+{
+ /* Dummy implementation. To be replaced. */
+ return kmap_atomic(page);
+}
+
bool vma_is_encrypted(struct vm_area_struct *vma)
{
return pgprot_val(vma->vm_page_prot) & mktme_keyid_mask;
@@ -20,3 +27,34 @@ int vma_keyid(struct vm_area_struct *vma)
prot = pgprot_val(vma->vm_page_prot);
return (prot & mktme_keyid_mask) >> mktme_keyid_shift;
}
+
+void prep_encrypt_page(struct page *page, gfp_t gfp, unsigned int order)
+{
+ void *v = page_to_virt(page);
+
+ /*
+ * The hardware/CPU does not enforce coherency between mappings of the
+ * same physical page with different KeyIDs or encrypt ion keys.
+ * We are responsible for cache management.
+ *
+ * We have to flush cache on allocation and freeing of encrypted page.
+ * Failing to do this may lead to data corruption.
+ */
+ clflush_cache_range(v, PAGE_SIZE << order);
+
+ WARN_ONCE(gfp & __GFP_ZERO, "__GFP_ZERO is useless for encrypted pages");
+}
+
+struct page *__alloc_zeroed_encrypted_user_highpage(gfp_t gfp,
+ struct vm_area_struct *vma, unsigned long vaddr)
+{
+ struct page *page;
+ void *v;
+
+ page = alloc_page_vma(gfp | GFP_HIGHUSER, vma, vaddr);
+ v = kmap_atomic_keyid(page, vma_keyid(vma));
+ clear_page(v);
+ kunmap_atomic(v);
+
+ return page;
+}
--
2.16.1
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
next prev parent reply other threads:[~2018-03-05 16:28 UTC|newest]
Thread overview: 53+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-03-05 16:25 [RFC, PATCH 00/22] Partial MKTME enabling Kirill A. Shutemov
2018-03-05 16:25 ` [RFC, PATCH 01/22] x86/cpufeatures: Add Intel Total Memory Encryption cpufeature Kirill A. Shutemov
2018-03-05 16:25 ` [RFC, PATCH 02/22] x86/tme: Detect if TME and MKTME is activated by BIOS Kirill A. Shutemov
2018-03-05 16:25 ` [RFC, PATCH 03/22] x86/cpufeatures: Add Intel PCONFIG cpufeature Kirill A. Shutemov
2018-03-05 16:25 ` [RFC, PATCH 04/22] x86/pconfig: Detect PCONFIG targets Kirill A. Shutemov
2018-03-05 16:25 ` [RFC, PATCH 05/22] x86/pconfig: Provide defines and helper to run MKTME_KEY_PROG leaf Kirill A. Shutemov
2018-03-05 16:25 ` [RFC, PATCH 06/22] x86/mm: Decouple dynamic __PHYSICAL_MASK from AMD SME Kirill A. Shutemov
2018-03-05 16:25 ` [RFC, PATCH 07/22] x86/mm: Mask out KeyID bits from page table entry pfn Kirill A. Shutemov
2018-03-22 15:55 ` Punit Agrawal
2018-03-05 16:25 ` [RFC, PATCH 08/22] mm: Introduce __GFP_ENCRYPT Kirill A. Shutemov
2018-03-22 16:02 ` Punit Agrawal
2018-03-05 16:25 ` [RFC, PATCH 09/22] mm, rmap: Add arch-specific field into anon_vma Kirill A. Shutemov
2018-03-05 16:25 ` [RFC, PATCH 10/22] mm/shmem: Zero out unused vma fields in shmem_pseudo_vma_init() Kirill A. Shutemov
2018-03-05 16:25 ` [RFC, PATCH 11/22] mm: Use __GFP_ENCRYPT for pages in encrypted VMAs Kirill A. Shutemov
2018-03-05 16:26 ` [RFC, PATCH 12/22] mm: Do no merge vma with different encryption KeyIDs Kirill A. Shutemov
2018-03-05 16:26 ` [RFC, PATCH 13/22] mm, rmap: Free encrypted pages once mapcount drops to zero Kirill A. Shutemov
2018-03-05 19:12 ` Dave Hansen
2018-03-06 8:18 ` Kirill A. Shutemov
2018-03-05 19:13 ` Dave Hansen
2018-03-06 8:27 ` Kirill A. Shutemov
2018-03-06 14:59 ` Dave Hansen
2018-03-06 15:00 ` Kirill A. Shutemov
2018-03-05 16:26 ` [RFC, PATCH 14/22] mm, khugepaged: Do not collapse pages in encrypted VMAs Kirill A. Shutemov
2018-03-05 16:26 ` [RFC, PATCH 15/22] x86/mm: Introduce variables to store number, shift and mask of KeyIDs Kirill A. Shutemov
2018-03-05 16:26 ` [RFC, PATCH 16/22] x86/mm: Preserve KeyID on pte_modify() and pgprot_modify() Kirill A. Shutemov
2018-03-05 19:09 ` Dave Hansen
2018-03-06 8:30 ` Kirill A. Shutemov
2018-03-05 16:26 ` [RFC, PATCH 17/22] x86/mm: Implement vma_is_encrypted() and vma_keyid() Kirill A. Shutemov
2018-03-05 16:26 ` Kirill A. Shutemov [this message]
2018-03-05 19:03 ` [RFC, PATCH 18/22] x86/mm: Handle allocation of encrypted pages Dave Hansen
2018-03-06 8:34 ` Kirill A. Shutemov
2018-03-05 19:07 ` Dave Hansen
2018-03-06 8:36 ` Kirill A. Shutemov
2018-03-05 16:26 ` [RFC, PATCH 19/22] x86/mm: Implement free_encrypt_page() Kirill A. Shutemov
2018-03-05 19:00 ` Dave Hansen
2018-03-06 8:38 ` Kirill A. Shutemov
2018-03-05 19:07 ` Dave Hansen
2018-03-06 8:54 ` Kirill A. Shutemov
2018-03-06 13:52 ` Dave Hansen
2018-03-06 14:09 ` Kirill A. Shutemov
2018-03-20 12:50 ` Kirill A. Shutemov
2018-03-27 14:44 ` Kirill A. Shutemov
2018-03-05 16:26 ` [RFC, PATCH 20/22] x86/mm: Implement anon_vma_encrypted() and anon_vma_keyid() Kirill A. Shutemov
2018-03-05 16:26 ` [RFC, PATCH 21/22] x86/mm: Introduce page_keyid() and page_encrypted() Kirill A. Shutemov
2018-03-05 17:08 ` Dave Hansen
2018-03-06 8:57 ` Kirill A. Shutemov
2018-03-06 14:56 ` Dave Hansen
2018-03-06 14:58 ` Kirill A. Shutemov
2018-03-06 15:04 ` Dave Hansen
2018-03-05 16:26 ` [RFC, PATCH 22/22] x86: Introduce CONFIG_X86_INTEL_MKTME Kirill A. Shutemov
2018-03-05 18:30 ` [RFC, PATCH 00/22] Partial MKTME enabling Christoph Hellwig
2018-03-05 19:05 ` Matthew Wilcox
2018-03-06 8:58 ` Kirill A. Shutemov
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=20180305162610.37510-19-kirill.shutemov@linux.intel.com \
--to=kirill.shutemov@linux.intel.com \
--cc=dave.hansen@intel.com \
--cc=hpa@zytor.com \
--cc=kai.huang@linux.intel.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mingo@redhat.com \
--cc=tglx@linutronix.de \
--cc=thomas.lendacky@amd.com \
--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).