• Dave Hansen's avatar
    mm/core: Do not enforce PKEY permissions on remote mm access · 1b2ee126
    Dave Hansen authored
    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: default avatarDave Hansen <dave.hansen@linux.intel.com>
    Reviewed-by: default avatarThomas 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: default avatarIngo Molnar <mingo@kernel.org>
    1b2ee126
mm_hooks.h 946 Bytes