aboutsummaryrefslogtreecommitdiffstats
path: root/mm/ksm.c
diff options
context:
space:
mode:
authorDave Hansen <dave.hansen@linux.intel.com>2016-02-12 16:02:21 -0500
committerIngo Molnar <mingo@kernel.org>2016-02-18 13:46:28 -0500
commit1b2ee1266ea647713dbaf44825967c180dfc8d76 (patch)
tree45a0ed817b74311c0dc89eafd217fc3bd7346c0a /mm/ksm.c
parent9d95b1759e0504890049deb2de62e31d7c241c30 (diff)
mm/core: Do not enforce PKEY permissions on remote mm access
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. Signed-off-by: Dave Hansen <dave.hansen@linux.intel.com> Reviewed-by: Thomas Gleixner <tglx@linutronix.de> Cc: Alexey Kardashevskiy <aik@ozlabs.ru> Cc: Andrea Arcangeli <aarcange@redhat.com> Cc: Andrew Morton <akpm@linux-foundation.org> Cc: Andy Lutomirski <luto@amacapital.net> Cc: Andy Lutomirski <luto@kernel.org> Cc: Arnd Bergmann <arnd@arndb.de> Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org> Cc: Boaz Harrosh <boaz@plexistor.com> Cc: Borislav Petkov <bp@alien8.de> Cc: Brian Gerst <brgerst@gmail.com> Cc: Dan Williams <dan.j.williams@intel.com> Cc: Dave Chinner <dchinner@redhat.com> Cc: Dave Hansen <dave.hansen@linux.intel.com> Cc: David Gibson <david@gibson.dropbear.id.au> Cc: Denys Vlasenko <dvlasenk@redhat.com> Cc: Dominik Dingel <dingel@linux.vnet.ibm.com> Cc: Dominik Vogt <vogt@linux.vnet.ibm.com> Cc: Eric B Munson <emunson@akamai.com> Cc: Geliang Tang <geliangtang@163.com> Cc: Guan Xuetao <gxt@mprc.pku.edu.cn> Cc: H. Peter Anvin <hpa@zytor.com> Cc: Heiko Carstens <heiko.carstens@de.ibm.com> Cc: Hugh Dickins <hughd@google.com> Cc: Jan Kara <jack@suse.cz> Cc: Jason Low <jason.low2@hp.com> Cc: Jerome Marchand <jmarchan@redhat.com> Cc: Joerg Roedel <joro@8bytes.org> Cc: Kirill A. Shutemov <kirill.shutemov@linux.intel.com> Cc: Konstantin Khlebnikov <koct9i@gmail.com> Cc: Laurent Dufour <ldufour@linux.vnet.ibm.com> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Martin Schwidefsky <schwidefsky@de.ibm.com> Cc: Matthew Wilcox <willy@linux.intel.com> Cc: Mel Gorman <mgorman@suse.de> Cc: Michael Ellerman <mpe@ellerman.id.au> Cc: Michal Hocko <mhocko@suse.com> Cc: Mikulas Patocka <mpatocka@redhat.com> Cc: Minchan Kim <minchan@kernel.org> Cc: Oleg Nesterov <oleg@redhat.com> Cc: Paul Mackerras <paulus@samba.org> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Rik van Riel <riel@redhat.com> Cc: Sasha Levin <sasha.levin@oracle.com> Cc: Shachar Raindel <raindel@mellanox.com> Cc: Vlastimil Babka <vbabka@suse.cz> Cc: Xie XiuQi <xiexiuqi@huawei.com> Cc: iommu@lists.linux-foundation.org Cc: linux-arch@vger.kernel.org Cc: linux-kernel@vger.kernel.org Cc: linux-mm@kvack.org Cc: linux-s390@vger.kernel.org Cc: linuxppc-dev@lists.ozlabs.org Signed-off-by: Ingo Molnar <mingo@kernel.org>
Diffstat (limited to 'mm/ksm.c')
-rw-r--r--mm/ksm.c10
1 files changed, 8 insertions, 2 deletions
diff --git a/mm/ksm.c b/mm/ksm.c
index c2013f638d11..b99e828172f6 100644
--- a/mm/ksm.c
+++ b/mm/ksm.c
@@ -359,6 +359,10 @@ static inline bool ksm_test_exit(struct mm_struct *mm)
359 * in case the application has unmapped and remapped mm,addr meanwhile. 359 * in case the application has unmapped and remapped mm,addr meanwhile.
360 * Could a ksm page appear anywhere else? Actually yes, in a VM_PFNMAP 360 * Could a ksm page appear anywhere else? Actually yes, in a VM_PFNMAP
361 * mmap of /dev/mem or /dev/kmem, where we would not want to touch it. 361 * mmap of /dev/mem or /dev/kmem, where we would not want to touch it.
362 *
363 * FAULT_FLAG/FOLL_REMOTE are because we do this outside the context
364 * of the process that owns 'vma'. We also do not want to enforce
365 * protection keys here anyway.
362 */ 366 */
363static int break_ksm(struct vm_area_struct *vma, unsigned long addr) 367static int break_ksm(struct vm_area_struct *vma, unsigned long addr)
364{ 368{
@@ -367,12 +371,14 @@ static int break_ksm(struct vm_area_struct *vma, unsigned long addr)
367 371
368 do { 372 do {
369 cond_resched(); 373 cond_resched();
370 page = follow_page(vma, addr, FOLL_GET | FOLL_MIGRATION); 374 page = follow_page(vma, addr,
375 FOLL_GET | FOLL_MIGRATION | FOLL_REMOTE);
371 if (IS_ERR_OR_NULL(page)) 376 if (IS_ERR_OR_NULL(page))
372 break; 377 break;
373 if (PageKsm(page)) 378 if (PageKsm(page))
374 ret = handle_mm_fault(vma->vm_mm, vma, addr, 379 ret = handle_mm_fault(vma->vm_mm, vma, addr,
375 FAULT_FLAG_WRITE); 380 FAULT_FLAG_WRITE |
381 FAULT_FLAG_REMOTE);
376 else 382 else
377 ret = VM_FAULT_WRITE; 383 ret = VM_FAULT_WRITE;
378 put_page(page); 384 put_page(page);