linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Dave Hansen <dave@sr71.net>
To: linux-kernel@vger.kernel.org
Cc: linux-mm@kvack.org, x86@kernel.org,
	torvalds@linux-foundation.org, Dave Hansen <dave@sr71.net>,
	dave.hansen@linux.intel.com, linux-arch@vger.kernel.org
Subject: [PATCH 20/33] mm: do not enforce PKEY permissions on "foreign" mm access
Date: Fri, 12 Feb 2016 13:02:21 -0800	[thread overview]
Message-ID: <20160212210220.9EC8AC72@viggo.jf.intel.com> (raw)
In-Reply-To: <20160212210152.9CAD15B0@viggo.jf.intel.com>


From: Dave Hansen <dave.hansen@linux.intel.com>

We try to enforce protection keys in software the same way that we
do in hardware.  (See long example below).

But, we only want to do this when accessing our *own* process's
memory.  If GDB set PKRU[6].AD=1 (disable access to PKEY 6), then
tried to PTRACE_POKE a target process which just happened to have
some mprotect_pkey(pkey=6) memory, we do *not* want to deny the
debugger access to that memory.  PKRU is fundamentally a
thread-local structure and we do not want to enforce it on access
to _another_ thread's data.

This gets especially tricky when we have workqueues or other
delayed-work mechanisms that might run in a random process's context.
We can check that we only enforce pkeys when operating on our *own* mm,
but delayed work gets performed when a random user context is active.
We might end up with a situation where a delayed-work gup fails when
running randomly under its "own" task but succeeds when running under
another process.  We want to avoid that.

To avoid that, we use the new GUP flag: FOLL_REMOTE and add a
fault flag: FAULT_FLAG_REMOTE.  They indicate that we are
walking an mm which is not guranteed to be the same as
current->mm and should not be subject to protection key
enforcement.

Thanks to Jerome Glisse for pointing out this scenario.

*** Why do we enforce protection keys in software?? ***

Imagine that we disabled access to the memory pointer to by 'buf'.
The, we implemented sys_write() like this:

	sys_read(fd, buf, len...)
	{
		struct page *page = follow_page(buf);
		void *buf_mapped = kmap(page);
		memcpy(buf_mapped, fd_data, len);
		...
	}

This writes to 'buf' via a *kernel* mapping, without a protection
key.  While this implementation does the same thing:

	sys_read(fd, buf, len...)
	{
		copy_to_user(buf, fd_data, len);
		...
	}

but would hit a protection key fault because the userspace 'buf'
mapping has a protection key set.

To provide consistency, and to make key-protected memory work
as much like mprotect()ed memory as possible, we try to enforce
the same protections as the hardware would when the *kernel* walks
the page tables (and other mm structures).

Signed-off-by: Dave Hansen <dave.hansen@linux.intel.com>
Cc: linux-arch@vger.kernel.org
---

 b/arch/powerpc/include/asm/mmu_context.h   |    3 ++-
 b/arch/s390/include/asm/mmu_context.h      |    3 ++-
 b/arch/unicore32/include/asm/mmu_context.h |    3 ++-
 b/arch/x86/include/asm/mmu_context.h       |    5 +++--
 b/drivers/iommu/amd_iommu_v2.c             |    1 +
 b/include/asm-generic/mm_hooks.h           |    3 ++-
 b/include/linux/mm.h                       |    1 +
 b/mm/gup.c                                 |   15 ++++++++++-----
 b/mm/ksm.c                                 |   10 ++++++++--
 b/mm/memory.c                              |    3 ++-
 10 files changed, 33 insertions(+), 14 deletions(-)

diff -puN arch/powerpc/include/asm/mmu_context.h~pkeys-14-gup-fault-foreign-flag arch/powerpc/include/asm/mmu_context.h
--- a/arch/powerpc/include/asm/mmu_context.h~pkeys-14-gup-fault-foreign-flag	2016-02-12 10:44:22.650540035 -0800
+++ b/arch/powerpc/include/asm/mmu_context.h	2016-02-12 10:44:22.668540858 -0800
@@ -148,7 +148,8 @@ static inline void arch_bprm_mm_init(str
 {
 }
 
-static inline bool arch_vma_access_permitted(struct vm_area_struct *vma, bool write)
+static inline bool arch_vma_access_permitted(struct vm_area_struct *vma,
+		bool write, bool foreign)
 {
 	/* by default, allow everything */
 	return true;
diff -puN arch/s390/include/asm/mmu_context.h~pkeys-14-gup-fault-foreign-flag arch/s390/include/asm/mmu_context.h
--- a/arch/s390/include/asm/mmu_context.h~pkeys-14-gup-fault-foreign-flag	2016-02-12 10:44:22.652540127 -0800
+++ b/arch/s390/include/asm/mmu_context.h	2016-02-12 10:44:22.669540904 -0800
@@ -130,7 +130,8 @@ static inline void arch_bprm_mm_init(str
 {
 }
 
-static inline bool arch_vma_access_permitted(struct vm_area_struct *vma, bool write)
+static inline bool arch_vma_access_permitted(struct vm_area_struct *vma,
+		bool write, bool foreign)
 {
 	/* by default, allow everything */
 	return true;
diff -puN arch/unicore32/include/asm/mmu_context.h~pkeys-14-gup-fault-foreign-flag arch/unicore32/include/asm/mmu_context.h
--- a/arch/unicore32/include/asm/mmu_context.h~pkeys-14-gup-fault-foreign-flag	2016-02-12 10:44:22.654540218 -0800
+++ b/arch/unicore32/include/asm/mmu_context.h	2016-02-12 10:44:22.669540904 -0800
@@ -97,7 +97,8 @@ static inline void arch_bprm_mm_init(str
 {
 }
 
-static inline bool arch_vma_access_permitted(struct vm_area_struct *vma, bool write)
+static inline bool arch_vma_access_permitted(struct vm_area_struct *vma,
+		bool write, bool foreign)
 {
 	/* by default, allow everything */
 	return true;
diff -puN arch/x86/include/asm/mmu_context.h~pkeys-14-gup-fault-foreign-flag arch/x86/include/asm/mmu_context.h
--- a/arch/x86/include/asm/mmu_context.h~pkeys-14-gup-fault-foreign-flag	2016-02-12 10:44:22.655540264 -0800
+++ b/arch/x86/include/asm/mmu_context.h	2016-02-12 10:44:22.669540904 -0800
@@ -322,10 +322,11 @@ static inline bool vma_is_foreign(struct
 	return false;
 }
 
-static inline bool arch_vma_access_permitted(struct vm_area_struct *vma, bool write)
+static inline bool arch_vma_access_permitted(struct vm_area_struct *vma,
+		bool write, bool foreign)
 {
 	/* allow access if the VMA is not one from this process */
-	if (vma_is_foreign(vma))
+	if (foreign || vma_is_foreign(vma))
 		return true;
 	return __pkru_allows_pkey(vma_pkey(vma), write);
 }
diff -puN drivers/iommu/amd_iommu_v2.c~pkeys-14-gup-fault-foreign-flag drivers/iommu/amd_iommu_v2.c
--- a/drivers/iommu/amd_iommu_v2.c~pkeys-14-gup-fault-foreign-flag	2016-02-12 10:44:22.657540355 -0800
+++ b/drivers/iommu/amd_iommu_v2.c	2016-02-12 10:44:22.670540949 -0800
@@ -526,6 +526,7 @@ static void do_fault(struct work_struct
 		flags |= FAULT_FLAG_USER;
 	if (fault->flags & PPR_FAULT_WRITE)
 		flags |= FAULT_FLAG_WRITE;
+	flags |= FAULT_FLAG_REMOTE;
 
 	down_read(&mm->mmap_sem);
 	vma = find_extend_vma(mm, address);
diff -puN include/asm-generic/mm_hooks.h~pkeys-14-gup-fault-foreign-flag include/asm-generic/mm_hooks.h
--- a/include/asm-generic/mm_hooks.h~pkeys-14-gup-fault-foreign-flag	2016-02-12 10:44:22.658540401 -0800
+++ b/include/asm-generic/mm_hooks.h	2016-02-12 10:44:22.670540949 -0800
@@ -26,7 +26,8 @@ static inline void arch_bprm_mm_init(str
 {
 }
 
-static inline bool arch_vma_access_permitted(struct vm_area_struct *vma, bool write)
+static inline bool arch_vma_access_permitted(struct vm_area_struct *vma,
+		bool write, bool foreign)
 {
 	/* by default, allow everything */
 	return true;
diff -puN include/linux/mm.h~pkeys-14-gup-fault-foreign-flag include/linux/mm.h
--- a/include/linux/mm.h~pkeys-14-gup-fault-foreign-flag	2016-02-12 10:44:22.660540492 -0800
+++ b/include/linux/mm.h	2016-02-12 10:44:22.671540995 -0800
@@ -251,6 +251,7 @@ extern pgprot_t protection_map[16];
 #define FAULT_FLAG_KILLABLE	0x10	/* The fault task is in SIGKILL killable region */
 #define FAULT_FLAG_TRIED	0x20	/* Second try */
 #define FAULT_FLAG_USER		0x40	/* The fault originated in userspace */
+#define FAULT_FLAG_REMOTE	0x80	/* faulting for non current tsk/mm */
 
 /*
  * vm_fault is filled by the the pagefault handler and passed to the vma's
diff -puN mm/gup.c~pkeys-14-gup-fault-foreign-flag mm/gup.c
--- a/mm/gup.c~pkeys-14-gup-fault-foreign-flag	2016-02-12 10:44:22.662540584 -0800
+++ b/mm/gup.c	2016-02-12 10:44:22.672541041 -0800
@@ -365,6 +365,8 @@ static int faultin_page(struct task_stru
 		return -ENOENT;
 	if (*flags & FOLL_WRITE)
 		fault_flags |= FAULT_FLAG_WRITE;
+	if (*flags & FOLL_REMOTE)
+		fault_flags |= FAULT_FLAG_REMOTE;
 	if (nonblocking)
 		fault_flags |= FAULT_FLAG_ALLOW_RETRY;
 	if (*flags & FOLL_NOWAIT)
@@ -415,11 +417,13 @@ static int faultin_page(struct task_stru
 static int check_vma_flags(struct vm_area_struct *vma, unsigned long gup_flags)
 {
 	vm_flags_t vm_flags = vma->vm_flags;
+	int write = (gup_flags & FOLL_WRITE);
+	int foreign = (gup_flags & FOLL_REMOTE);
 
 	if (vm_flags & (VM_IO | VM_PFNMAP))
 		return -EFAULT;
 
-	if (gup_flags & FOLL_WRITE) {
+	if (write) {
 		if (!(vm_flags & VM_WRITE)) {
 			if (!(gup_flags & FOLL_FORCE))
 				return -EFAULT;
@@ -445,7 +449,7 @@ static int check_vma_flags(struct vm_are
 		if (!(vm_flags & VM_MAYREAD))
 			return -EFAULT;
 	}
-	if (!arch_vma_access_permitted(vma, (gup_flags & FOLL_WRITE)))
+	if (!arch_vma_access_permitted(vma, write, foreign))
 		return -EFAULT;
 	return 0;
 }
@@ -615,7 +619,8 @@ EXPORT_SYMBOL(__get_user_pages);
 
 bool vma_permits_fault(struct vm_area_struct *vma, unsigned int fault_flags)
 {
-	bool write = !!(fault_flags & FAULT_FLAG_WRITE);
+	bool write   = !!(fault_flags & FAULT_FLAG_WRITE);
+	bool foreign = !!(fault_flags & FAULT_FLAG_REMOTE);
 	vm_flags_t vm_flags = write ? VM_WRITE : VM_READ;
 
 	if (!(vm_flags & vma->vm_flags))
@@ -623,9 +628,9 @@ bool vma_permits_fault(struct vm_area_st
 
 	/*
 	 * The architecture might have a hardware protection
-	 * mechanism other than read/write that can deny access
+	 * mechanism other than read/write that can deny access.
 	 */
-	if (!arch_vma_access_permitted(vma, write))
+	if (!arch_vma_access_permitted(vma, write, foreign))
 		return false;
 
 	return true;
diff -puN mm/ksm.c~pkeys-14-gup-fault-foreign-flag mm/ksm.c
--- a/mm/ksm.c~pkeys-14-gup-fault-foreign-flag	2016-02-12 10:44:22.663540630 -0800
+++ b/mm/ksm.c	2016-02-12 10:44:22.673541087 -0800
@@ -359,6 +359,10 @@ static inline bool ksm_test_exit(struct
  * in case the application has unmapped and remapped mm,addr meanwhile.
  * Could a ksm page appear anywhere else?  Actually yes, in a VM_PFNMAP
  * mmap of /dev/mem or /dev/kmem, where we would not want to touch it.
+ *
+ * FAULT_FLAG/FOLL_REMOTE are because we do this outside the context
+ * of the process that owns 'vma'.  We also do not want to enforce
+ * protection keys here anyway.
  */
 static int break_ksm(struct vm_area_struct *vma, unsigned long addr)
 {
@@ -367,12 +371,14 @@ static int break_ksm(struct vm_area_stru
 
 	do {
 		cond_resched();
-		page = follow_page(vma, addr, FOLL_GET | FOLL_MIGRATION);
+		page = follow_page(vma, addr,
+				FOLL_GET | FOLL_MIGRATION | FOLL_REMOTE);
 		if (IS_ERR_OR_NULL(page))
 			break;
 		if (PageKsm(page))
 			ret = handle_mm_fault(vma->vm_mm, vma, addr,
-							FAULT_FLAG_WRITE);
+							FAULT_FLAG_WRITE |
+							FAULT_FLAG_REMOTE);
 		else
 			ret = VM_FAULT_WRITE;
 		put_page(page);
diff -puN mm/memory.c~pkeys-14-gup-fault-foreign-flag mm/memory.c
--- a/mm/memory.c~pkeys-14-gup-fault-foreign-flag	2016-02-12 10:44:22.665540721 -0800
+++ b/mm/memory.c	2016-02-12 10:44:22.674541132 -0800
@@ -3358,7 +3358,8 @@ static int __handle_mm_fault(struct mm_s
 	pmd_t *pmd;
 	pte_t *pte;
 
-	if (!arch_vma_access_permitted(vma, flags & FAULT_FLAG_WRITE))
+	if (!arch_vma_access_permitted(vma, flags & FAULT_FLAG_WRITE,
+					    flags & FAULT_FLAG_REMOTE))
 		return VM_FAULT_SIGSEGV;
 
 	if (unlikely(is_vm_hugetlb_page(vma)))
_

--
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>

  parent reply	other threads:[~2016-02-12 21:02 UTC|newest]

Thread overview: 46+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-02-12 21:01 [PATCH 00/33] x86: Memory Protection Keys (v10) Dave Hansen
2016-02-12 21:01 ` [PATCH 01/33] mm: introduce get_user_pages_remote() Dave Hansen
2016-02-15  6:09   ` Balbir Singh
2016-02-15 16:29     ` Dave Hansen
2016-02-15  6:14   ` Srikar Dronamraju
2016-02-12 21:01 ` [PATCH 02/33] mm: overload get_user_pages() functions Dave Hansen
2016-02-16  8:36   ` Ingo Molnar
2016-02-17 18:15     ` Dave Hansen
2016-02-12 21:01 ` [PATCH 03/33] mm, gup: switch callers of get_user_pages() to not pass tsk/mm Dave Hansen
2016-02-12 21:01 ` [PATCH 04/33] x86, fpu: add placeholder for Processor Trace XSAVE state Dave Hansen
2016-02-12 21:02 ` [PATCH 05/33] x86, pkeys: Add Kconfig option Dave Hansen
2016-02-12 21:02 ` [PATCH 06/33] x86, pkeys: cpuid bit definition Dave Hansen
2016-02-12 21:02 ` [PATCH 07/33] x86, pkeys: define new CR4 bit Dave Hansen
2016-02-12 21:02 ` [PATCH 08/33] x86, pkeys: add PKRU xsave fields and data structure(s) Dave Hansen
2016-02-12 21:02 ` [PATCH 09/33] x86, pkeys: PTE bits for storing protection key Dave Hansen
2016-02-12 21:02 ` [PATCH 10/33] x86, pkeys: new page fault error code bit: PF_PK Dave Hansen
2016-02-12 21:02 ` [PATCH 11/33] x86, pkeys: store protection in high VMA flags Dave Hansen
2016-02-12 21:02 ` [PATCH 12/33] x86, pkeys: arch-specific protection bits Dave Hansen
2016-02-12 21:02 ` [PATCH 13/33] x86, pkeys: pass VMA down in to fault signal generation code Dave Hansen
2016-02-12 21:02 ` [PATCH 14/33] signals, pkeys: notify userspace about protection key faults Dave Hansen
2016-02-12 21:02 ` [PATCH 15/33] x86, pkeys: fill in pkey field in siginfo Dave Hansen
2016-02-12 21:02 ` [PATCH 16/33] x86, pkeys: add functions to fetch PKRU Dave Hansen
2016-02-12 21:02 ` [PATCH 17/33] mm: factor out VMA fault permission checking Dave Hansen
2016-02-12 21:02 ` [PATCH 18/33] x86, mm: simplify get_user_pages() PTE bit handling Dave Hansen
2016-02-12 21:02 ` [PATCH 19/33] x86, pkeys: check VMAs and PTEs for protection keys Dave Hansen
2016-02-12 21:02 ` Dave Hansen [this message]
2016-02-12 21:02 ` [PATCH 21/33] x86, pkeys: optimize fault handling in access_error() Dave Hansen
2016-02-12 21:02 ` [PATCH 22/33] x86, pkeys: differentiate instruction fetches Dave Hansen
2016-02-12 21:02 ` [PATCH 23/33] x86, pkeys: dump PKRU with other kernel registers Dave Hansen
2016-02-12 21:02 ` [PATCH 24/33] x86, pkeys: dump pkey from VMA in /proc/pid/smaps Dave Hansen
2016-02-12 21:02 ` [PATCH 25/33] x86, pkeys: add Kconfig prompt to existing config option Dave Hansen
2016-02-12 21:02 ` [PATCH 26/33] x86, pkeys: actually enable Memory Protection Keys in CPU Dave Hansen
2016-02-12 21:02 ` [PATCH 27/33] mm, multi-arch: pass a protection key in to calc_vm_flag_bits() Dave Hansen
2016-02-12 21:02 ` [PATCH 28/33] x86, pkeys: add arch_validate_pkey() Dave Hansen
2016-02-12 21:02 ` [PATCH 29/33] x86: separate out LDT init from context init Dave Hansen
2016-02-12 21:02 ` [PATCH 30/33] x86, fpu: allow setting of XSAVE state Dave Hansen
2016-02-12 21:02 ` [PATCH 31/33] x86, pkeys: allow kernel to modify user pkey rights register Dave Hansen
2016-02-12 21:02 ` [PATCH 32/33] x86, pkeys: create an x86 arch_calc_vm_prot_bits() for VMA flags Dave Hansen
2016-02-12 21:02 ` [PATCH 33/33] x86, pkeys: execute-only support Dave Hansen
2016-02-17 21:27   ` Kees Cook
2016-02-17 21:33     ` Dave Hansen
2016-02-17 21:36       ` Kees Cook
2016-02-17 22:17     ` Andy Lutomirski
2016-02-17 22:53       ` Dave Hansen
2016-02-18  0:46         ` Andy Lutomirski
2016-02-16  9:29 ` [PATCH 00/33] x86: Memory Protection Keys (v10) Ingo Molnar

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=20160212210220.9EC8AC72@viggo.jf.intel.com \
    --to=dave@sr71.net \
    --cc=dave.hansen@linux.intel.com \
    --cc=linux-arch@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=torvalds@linux-foundation.org \
    --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).