Commits on Mar 19, 2021

1. cifsd: fix error handling in ksmbd_server_init() …

   The error handling in ksmbd_server_init() uses "one function to free
   everything style" which is impossible to audit and leads to several
   canonical bugs.  When we free something that wasn't allocated it may be
   uninitialized, an error pointer, freed in a different function or we
   try freeing "foo->bar" when "foo" is a NULL pointer.  And since the
   code is impossible to audit then it leads to memory leaks.
   
   In the ksmbd_server_init() function, every goto will lead to a crash
   because we have not allocated the work queue but we call
   ksmbd_workqueue_destroy() which tries to flush a NULL work queue.
   Another bug is if ksmbd_init_buffer_pools() fails then it leads to a
   double free because we free "work_cache" twice.  A third type of bug is
   that we forgot to call ksmbd_release_inode_hash() so that is a resource
   leak.
   
   A better way to write error handling is for every function to clean up
   after itself and never leave things partially allocated.  Then we can
   use "free the last successfully allocated resource" style.  That way
   when someone is reading the code they can just track the last resource
   in their head and verify that the goto matches what they expect.
   
   In this patch I modified ksmbd_ipc_init() to clean up after itself and
   then I converted ksmbd_server_init() to use gotos to clean up.
   
   Fixes: cabcebc ("cifsd: introduce SMB3 kernel server")
   Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>

   

   error27 authored and intel-lab-lkp committed Mar 19, 2021
   cc0b000

2. Add linux-next specific files for 20210319 …

   Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>

   

   sfrothwell committed Mar 19, 2021
   f00397e

3. Merge branch 'akpm/master'

   

   sfrothwell committed Mar 19, 2021
   c3c9b29

4. secretmem: test: add basic selftest for memfd_secret(2) …

   The test verifies that file descriptor created with memfd_secret does not
   allow read/write operations, that secret memory mappings respect
   RLIMIT_MEMLOCK and that remote accesses with process_vm_read() and
   ptrace() to the secret memory fail.
   
   Link: https://lkml.kernel.org/r/20210303162209.8609-10-rppt@kernel.org
   Signed-off-by: Mike Rapoport <rppt@linux.ibm.com>
   Cc: Alexander Viro <viro@zeniv.linux.org.uk>
   Cc: Andy Lutomirski <luto@kernel.org>
   Cc: Arnd Bergmann <arnd@arndb.de>
   Cc: Borislav Petkov <bp@alien8.de>
   Cc: Catalin Marinas <catalin.marinas@arm.com>
   Cc: Christopher Lameter <cl@linux.com>
   Cc: Dan Williams <dan.j.williams@intel.com>
   Cc: Dave Hansen <dave.hansen@linux.intel.com>
   Cc: David Hildenbrand <david@redhat.com>
   Cc: Elena Reshetova <elena.reshetova@intel.com>
   Cc: Hagen Paul Pfeifer <hagen@jauu.net>
   Cc: "H. Peter Anvin" <hpa@zytor.com>
   Cc: Ingo Molnar <mingo@redhat.com>
   Cc: James Bottomley <jejb@linux.ibm.com>
   Cc: "Kirill A. Shutemov" <kirill@shutemov.name>
   Cc: Mark Rutland <mark.rutland@arm.com>
   Cc: Matthew Wilcox <willy@infradead.org>
   Cc: Michael Kerrisk <mtk.manpages@gmail.com>
   Cc: Palmer Dabbelt <palmer@dabbelt.com>
   Cc: Palmer Dabbelt <palmerdabbelt@google.com>
   Cc: Paul Walmsley <paul.walmsley@sifive.com>
   Cc: Peter Zijlstra <peterz@infradead.org>
   Cc: Rick Edgecombe <rick.p.edgecombe@intel.com>
   Cc: Roman Gushchin <guro@fb.com>
   Cc: Shakeel Butt <shakeelb@google.com>
   Cc: Shuah Khan <shuah@kernel.org>
   Cc: Thomas Gleixner <tglx@linutronix.de>
   Cc: Tycho Andersen <tycho@tycho.ws>
   Cc: Will Deacon <will@kernel.org>
   Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
   Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>

   

   rppt authored and sfrothwell committed Mar 19, 2021
   4d73c4f

5. arch, mm: wire up memfd_secret system call where relevant …

   Wire up memfd_secret system call on architectures that define
   ARCH_HAS_SET_DIRECT_MAP, namely arm64, risc-v and x86.
   
   Link: https://lkml.kernel.org/r/20210303162209.8609-9-rppt@kernel.org
   Signed-off-by: Mike Rapoport <rppt@linux.ibm.com>
   Acked-by: Palmer Dabbelt <palmerdabbelt@google.com>
   Acked-by: Arnd Bergmann <arnd@arndb.de>
   Acked-by: Catalin Marinas <catalin.marinas@arm.com>
   Cc: Alexander Viro <viro@zeniv.linux.org.uk>
   Cc: Andy Lutomirski <luto@kernel.org>
   Cc: Borislav Petkov <bp@alien8.de>
   Cc: Christopher Lameter <cl@linux.com>
   Cc: Dan Williams <dan.j.williams@intel.com>
   Cc: Dave Hansen <dave.hansen@linux.intel.com>
   Cc: David Hildenbrand <david@redhat.com>
   Cc: Elena Reshetova <elena.reshetova@intel.com>
   Cc: Hagen Paul Pfeifer <hagen@jauu.net>
   Cc: "H. Peter Anvin" <hpa@zytor.com>
   Cc: Ingo Molnar <mingo@redhat.com>
   Cc: James Bottomley <jejb@linux.ibm.com>
   Cc: "Kirill A. Shutemov" <kirill@shutemov.name>
   Cc: Mark Rutland <mark.rutland@arm.com>
   Cc: Matthew Wilcox <willy@infradead.org>
   Cc: Michael Kerrisk <mtk.manpages@gmail.com>
   Cc: Palmer Dabbelt <palmer@dabbelt.com>
   Cc: Paul Walmsley <paul.walmsley@sifive.com>
   Cc: Peter Zijlstra <peterz@infradead.org>
   Cc: Rick Edgecombe <rick.p.edgecombe@intel.com>
   Cc: Roman Gushchin <guro@fb.com>
   Cc: Shakeel Butt <shakeelb@google.com>
   Cc: Shuah Khan <shuah@kernel.org>
   Cc: Thomas Gleixner <tglx@linutronix.de>
   Cc: Tycho Andersen <tycho@tycho.ws>
   Cc: Will Deacon <will@kernel.org>
   Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
   Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>

   

   rppt authored and sfrothwell committed Mar 19, 2021
   6127410

6. PM: hibernate: disable when there are active secretmem users …

   It is unsafe to allow saving of secretmem areas to the hibernation
   snapshot as they would be visible after the resume and this essentially
   will defeat the purpose of secret memory mappings.
   
   Prevent hibernation whenever there are active secret memory users.
   
   Link: https://lkml.kernel.org/r/20210303162209.8609-8-rppt@kernel.org
   Signed-off-by: Mike Rapoport <rppt@linux.ibm.com>
   Cc: Alexander Viro <viro@zeniv.linux.org.uk>
   Cc: Andy Lutomirski <luto@kernel.org>
   Cc: Arnd Bergmann <arnd@arndb.de>
   Cc: Borislav Petkov <bp@alien8.de>
   Cc: Catalin Marinas <catalin.marinas@arm.com>
   Cc: Christopher Lameter <cl@linux.com>
   Cc: Dan Williams <dan.j.williams@intel.com>
   Cc: Dave Hansen <dave.hansen@linux.intel.com>
   Cc: David Hildenbrand <david@redhat.com>
   Cc: Elena Reshetova <elena.reshetova@intel.com>
   Cc: Hagen Paul Pfeifer <hagen@jauu.net>
   Cc: "H. Peter Anvin" <hpa@zytor.com>
   Cc: Ingo Molnar <mingo@redhat.com>
   Cc: James Bottomley <jejb@linux.ibm.com>
   Cc: "Kirill A. Shutemov" <kirill@shutemov.name>
   Cc: Mark Rutland <mark.rutland@arm.com>
   Cc: Matthew Wilcox <willy@infradead.org>
   Cc: Michael Kerrisk <mtk.manpages@gmail.com>
   Cc: Palmer Dabbelt <palmer@dabbelt.com>
   Cc: Palmer Dabbelt <palmerdabbelt@google.com>
   Cc: Paul Walmsley <paul.walmsley@sifive.com>
   Cc: Peter Zijlstra <peterz@infradead.org>
   Cc: Rick Edgecombe <rick.p.edgecombe@intel.com>
   Cc: Roman Gushchin <guro@fb.com>
   Cc: Shakeel Butt <shakeelb@google.com>
   Cc: Shuah Khan <shuah@kernel.org>
   Cc: Thomas Gleixner <tglx@linutronix.de>
   Cc: Tycho Andersen <tycho@tycho.ws>
   Cc: Will Deacon <will@kernel.org>
   Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
   Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>

   

   rppt authored and sfrothwell committed Mar 19, 2021
   b374f68

7. mm: introduce memfd_secret system call to create "secret" memory areas …

   Introduce "memfd_secret" system call with the ability to create memory
   areas visible only in the context of the owning process and not mapped not
   only to other processes but in the kernel page tables as well.
   
   The secretmem feature is off by default and the user must explicitly
   enable it at the boot time.
   
   Once secretmem is enabled, the user will be able to create a file
   descriptor using the memfd_secret() system call.  The memory areas created
   by mmap() calls from this file descriptor will be unmapped from the kernel
   direct map and they will be only mapped in the page table of the processes
   that have access to the file descriptor.
   
   The file descriptor based memory has several advantages over the
   "traditional" mm interfaces, such as mlock(), mprotect(), madvise().  File
   descriptor approach allows explict and controlled sharing of the memory
   areas, it allows to seal the operations.  Besides, file descriptor based
   memory paves the way for VMMs to remove the secret memory range from the
   userpace hipervisor process, for instance QEMU.  Andy Lutomirski says:
   
     "Getting fd-backed memory into a guest will take some possibly major
     work in the kernel, but getting vma-backed memory into a guest without
     mapping it in the host user address space seems much, much worse."
   
   memfd_secret() is made a dedicated system call rather than an extention to
   memfd_create() because it's purpose is to allow the user to create more
   secure memory mappings rather than to simply allow file based access to
   the memory.  Nowadays a new system call cost is negligible while it is way
   simpler for userspace to deal with a clear-cut system calls than with a
   multiplexer or an overloaded syscall.  Moreover, the initial
   implementation of memfd_secret() is completely distinct from
   memfd_create() so there is no much sense in overloading memfd_create()
   to begin with.  If there will be a need for code sharing between these
   implementation it can be easily achieved without a need to adjust user
   visible APIs.
   
   The secret memory remains accessible in the process context using uaccess
   primitives, but it is not exposed to the kernel otherwise; secret memory
   areas are removed from the direct map and functions in the
   follow_page()/get_user_page() family will refuse to return a page that
   belongs to the secret memory area.
   
   Once there will be a use case that will require exposing secretmem to the
   kernel it will be an opt-in request in the system call flags so that user
   would have to decide what data can be exposed to the kernel.
   
   Removing of the pages from the direct map may cause its fragmentation on
   architectures that use large pages to map the physical memory which
   affects the system performance.  However, the original Kconfig text for
   CONFIG_DIRECT_GBPAGES said that gigabyte pages in the direct map "...  can
   improve the kernel's performance a tiny bit ..." (commit 00d1c5e
   ("x86: add gbpages switches")) and the recent report [1] showed that "...
   although 1G mappings are a good default choice, there is no compelling
   evidence that it must be the only choice".  Hence, it is sufficient to
   have secretmem disabled by default with the ability of a system
   administrator to enable it at boot time.
   
   Pages in the secretmem regions are unevictable and unmovable to avoid
   accidental exposure of the sensitive data via swap or during page
   migration.
   
   Since the secretmem mappings are locked in memory they cannot exceed
   RLIMIT_MEMLOCK.  Since these mappings are already locked independently
   from mlock(), an attempt to mlock()/munlock() secretmem range would fail
   and mlockall()/munlockall() will ignore secretmem mappings.
   
   However, unlike mlock()ed memory, secretmem currently behaves more like
   long-term GUP: secretmem mappings are unmovable mappings directly consumed
   by user space.  With default limits, there is no excessive use of
   secretmem and it poses no real problem in combination with
   ZONE_MOVABLE/CMA, but in the future this should be addressed to allow
   balanced use of large amounts of secretmem along with ZONE_MOVABLE/CMA.
   
   A page that was a part of the secret memory area is cleared when it is
   freed to ensure the data is not exposed to the next user of that page.
   
   The following example demonstrates creation of a secret mapping (error
   handling is omitted):
   
   	fd = memfd_secret(0);
   	ftruncate(fd, MAP_SIZE);
   	ptr = mmap(NULL, MAP_SIZE, PROT_READ | PROT_WRITE,
   		   MAP_SHARED, fd, 0);
   
   [1] https://lore.kernel.org/linux-mm/213b4567-46ce-f116-9cdf-bbd0c884eb3c@linux.intel.com/
   Link: https://lkml.kernel.org/r/20210303162209.8609-7-rppt@kernel.org
   Signed-off-by: Mike Rapoport <rppt@linux.ibm.com>
   Acked-by: Hagen Paul Pfeifer <hagen@jauu.net>
   Cc: Alexander Viro <viro@zeniv.linux.org.uk>
   Cc: Andy Lutomirski <luto@kernel.org>
   Cc: Arnd Bergmann <arnd@arndb.de>
   Cc: Borislav Petkov <bp@alien8.de>
   Cc: Catalin Marinas <catalin.marinas@arm.com>
   Cc: Christopher Lameter <cl@linux.com>
   Cc: Dan Williams <dan.j.williams@intel.com>
   Cc: Dave Hansen <dave.hansen@linux.intel.com>
   Cc: Elena Reshetova <elena.reshetova@intel.com>
   Cc: "H. Peter Anvin" <hpa@zytor.com>
   Cc: Ingo Molnar <mingo@redhat.com>
   Cc: James Bottomley <jejb@linux.ibm.com>
   Cc: "Kirill A. Shutemov" <kirill@shutemov.name>
   Cc: Matthew Wilcox <willy@infradead.org>
   Cc: Mark Rutland <mark.rutland@arm.com>
   Cc: Michael Kerrisk <mtk.manpages@gmail.com>
   Cc: Palmer Dabbelt <palmer@dabbelt.com>
   Cc: Palmer Dabbelt <palmerdabbelt@google.com>
   Cc: Paul Walmsley <paul.walmsley@sifive.com>
   Cc: Peter Zijlstra <peterz@infradead.org>
   Cc: Rick Edgecombe <rick.p.edgecombe@intel.com>
   Cc: Roman Gushchin <guro@fb.com>
   Cc: Shakeel Butt <shakeelb@google.com>
   Cc: Shuah Khan <shuah@kernel.org>
   Cc: Thomas Gleixner <tglx@linutronix.de>
   Cc: Tycho Andersen <tycho@tycho.ws>
   Cc: Will Deacon <will@kernel.org>
   Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
   Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>

   

   rppt authored and sfrothwell committed Mar 19, 2021
   dafe5c0

8. set_memory: allow querying whether set_direct_map_*() is actually ena… …

   …bled
   
   On arm64, set_direct_map_*() functions may return 0 without actually
   changing the linear map.  This behaviour can be controlled using kernel
   parameters, so we need a way to determine at runtime whether calls to
   set_direct_map_invalid_noflush() and set_direct_map_default_noflush() have
   any effect.
   
   Extend set_memory API with can_set_direct_map() function that allows
   checking if calling set_direct_map_*() will actually change the page
   table, replace several occurrences of open coded checks in arm64 with the
   new function and provide a generic stub for architectures that always
   modify page tables upon calls to set_direct_map APIs.
   
   [arnd@arndb.de: arm64: kfence: fix header inclusion ]
   Link: https://lkml.kernel.org/r/20210303162209.8609-6-rppt@kernel.org
   Signed-off-by: Mike Rapoport <rppt@linux.ibm.com>
   Reviewed-by: Catalin Marinas <catalin.marinas@arm.com>
   Reviewed-by: David Hildenbrand <david@redhat.com>
   Cc: Alexander Viro <viro@zeniv.linux.org.uk>
   Cc: Andy Lutomirski <luto@kernel.org>
   Cc: Arnd Bergmann <arnd@arndb.de>
   Cc: Borislav Petkov <bp@alien8.de>
   Cc: Christopher Lameter <cl@linux.com>
   Cc: Dan Williams <dan.j.williams@intel.com>
   Cc: Dave Hansen <dave.hansen@linux.intel.com>
   Cc: Elena Reshetova <elena.reshetova@intel.com>
   Cc: Hagen Paul Pfeifer <hagen@jauu.net>
   Cc: "H. Peter Anvin" <hpa@zytor.com>
   Cc: Ingo Molnar <mingo@redhat.com>
   Cc: James Bottomley <jejb@linux.ibm.com>
   Cc: "Kirill A. Shutemov" <kirill@shutemov.name>
   Cc: Mark Rutland <mark.rutland@arm.com>
   Cc: Matthew Wilcox <willy@infradead.org>
   Cc: Michael Kerrisk <mtk.manpages@gmail.com>
   Cc: Palmer Dabbelt <palmer@dabbelt.com>
   Cc: Palmer Dabbelt <palmerdabbelt@google.com>
   Cc: Paul Walmsley <paul.walmsley@sifive.com>
   Cc: Peter Zijlstra <peterz@infradead.org>
   Cc: Rick Edgecombe <rick.p.edgecombe@intel.com>
   Cc: Roman Gushchin <guro@fb.com>
   Cc: Shakeel Butt <shakeelb@google.com>
   Cc: Shuah Khan <shuah@kernel.org>
   Cc: Thomas Gleixner <tglx@linutronix.de>
   Cc: Tycho Andersen <tycho@tycho.ws>
   Cc: Will Deacon <will@kernel.org>
   Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
   Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>

   

   rppt authored and sfrothwell committed Mar 19, 2021
   0a26343

9. set_memory: allow set_direct_map_*_noflush() for multiple pages …

   The underlying implementations of set_direct_map_invalid_noflush() and
   set_direct_map_default_noflush() allow updating multiple contiguous pages
   at once.
   
   Add numpages parameter to set_direct_map_*_noflush() to expose this
   ability with these APIs.
   
   Link: https://lkml.kernel.org/r/20210303162209.8609-5-rppt@kernel.org
   Signed-off-by: Mike Rapoport <rppt@linux.ibm.com>
   Acked-by: Catalin Marinas <catalin.marinas@arm.com>	[arm64]
   Cc: Alexander Viro <viro@zeniv.linux.org.uk>
   Cc: Andy Lutomirski <luto@kernel.org>
   Cc: Arnd Bergmann <arnd@arndb.de>
   Cc: Borislav Petkov <bp@alien8.de>
   Cc: Christopher Lameter <cl@linux.com>
   Cc: Dan Williams <dan.j.williams@intel.com>
   Cc: Dave Hansen <dave.hansen@linux.intel.com>
   Cc: David Hildenbrand <david@redhat.com>
   Cc: Elena Reshetova <elena.reshetova@intel.com>
   Cc: Hagen Paul Pfeifer <hagen@jauu.net>
   Cc: "H. Peter Anvin" <hpa@zytor.com>
   Cc: Ingo Molnar <mingo@redhat.com>
   Cc: James Bottomley <jejb@linux.ibm.com>
   Cc: "Kirill A. Shutemov" <kirill@shutemov.name>
   Cc: Mark Rutland <mark.rutland@arm.com>
   Cc: Matthew Wilcox <willy@infradead.org>
   Cc: Michael Kerrisk <mtk.manpages@gmail.com>
   Cc: Palmer Dabbelt <palmer@dabbelt.com>
   Cc: Palmer Dabbelt <palmerdabbelt@google.com>
   Cc: Paul Walmsley <paul.walmsley@sifive.com>
   Cc: Peter Zijlstra <peterz@infradead.org>
   Cc: Rick Edgecombe <rick.p.edgecombe@intel.com>
   Cc: Roman Gushchin <guro@fb.com>
   Cc: Shakeel Butt <shakeelb@google.com>
   Cc: Shuah Khan <shuah@kernel.org>
   Cc: Thomas Gleixner <tglx@linutronix.de>
   Cc: Tycho Andersen <tycho@tycho.ws>
   Cc: Will Deacon <will@kernel.org>
   Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
   Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>

   

   rppt authored and sfrothwell committed Mar 19, 2021
   8de2325

10. riscv/Kconfig: make direct map manipulation options depend on MMU …

    ARCH_HAS_SET_DIRECT_MAP and ARCH_HAS_SET_MEMORY configuration options have
    no meaning when CONFIG_MMU is disabled and there is no point to enable
    them for the nommu case.
    
    Add an explicit dependency on MMU for these options.
    
    Link: https://lkml.kernel.org/r/20210303162209.8609-4-rppt@kernel.org
    Signed-off-by: Mike Rapoport <rppt@linux.ibm.com>
    Reported-by: kernel test robot <lkp@intel.com>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>

    

    rppt authored and sfrothwell committed Mar 19, 2021
    2521602

11. mmap: make mlock_future_check() global …

    It will be used by the upcoming secret memory implementation.
    
    Link: https://lkml.kernel.org/r/20210303162209.8609-3-rppt@kernel.org
    Signed-off-by: Mike Rapoport <rppt@linux.ibm.com>
    Cc: Alexander Viro <viro@zeniv.linux.org.uk>
    Cc: Andy Lutomirski <luto@kernel.org>
    Cc: Arnd Bergmann <arnd@arndb.de>
    Cc: Borislav Petkov <bp@alien8.de>
    Cc: Catalin Marinas <catalin.marinas@arm.com>
    Cc: Christopher Lameter <cl@linux.com>
    Cc: Dan Williams <dan.j.williams@intel.com>
    Cc: Dave Hansen <dave.hansen@linux.intel.com>
    Cc: David Hildenbrand <david@redhat.com>
    Cc: Elena Reshetova <elena.reshetova@intel.com>
    Cc: Hagen Paul Pfeifer <hagen@jauu.net>
    Cc: "H. Peter Anvin" <hpa@zytor.com>
    Cc: Ingo Molnar <mingo@redhat.com>
    Cc: James Bottomley <jejb@linux.ibm.com>
    Cc: "Kirill A. Shutemov" <kirill@shutemov.name>
    Cc: Mark Rutland <mark.rutland@arm.com>
    Cc: Matthew Wilcox <willy@infradead.org>
    Cc: Michael Kerrisk <mtk.manpages@gmail.com>
    Cc: Palmer Dabbelt <palmer@dabbelt.com>
    Cc: Palmer Dabbelt <palmerdabbelt@google.com>
    Cc: Paul Walmsley <paul.walmsley@sifive.com>
    Cc: Peter Zijlstra <peterz@infradead.org>
    Cc: Rick Edgecombe <rick.p.edgecombe@intel.com>
    Cc: Roman Gushchin <guro@fb.com>
    Cc: Shakeel Butt <shakeelb@google.com>
    Cc: Shuah Khan <shuah@kernel.org>
    Cc: Thomas Gleixner <tglx@linutronix.de>
    Cc: Tycho Andersen <tycho@tycho.ws>
    Cc: Will Deacon <will@kernel.org>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>

    

    rppt authored and sfrothwell committed Mar 19, 2021
    4ea6eb8

12. mm: add definition of PMD_PAGE_ORDER …

    Patch series "mm: introduce memfd_secret system call to create "secret" memory areas", v18.
    
    This is an implementation of "secret" mappings backed by a file
    descriptor.
    
    The file descriptor backing secret memory mappings is created using a
    dedicated memfd_secret system call The desired protection mode for the
    memory is configured using flags parameter of the system call.  The mmap()
    of the file descriptor created with memfd_secret() will create a "secret"
    memory mapping.  The pages in that mapping will be marked as not present
    in the direct map and will be present only in the page table of the owning
    mm.
    
    Although normally Linux userspace mappings are protected from other users,
    such secret mappings are useful for environments where a hostile tenant is
    trying to trick the kernel into giving them access to other tenants
    mappings.
    
    Additionally, in the future the secret mappings may be used as a mean to
    protect guest memory in a virtual machine host.
    
    For demonstration of secret memory usage we've created a userspace library
    
    https://git.kernel.org/pub/scm/linux/kernel/git/jejb/secret-memory-preloader.git
    
    that does two things: the first is act as a preloader for openssl to
    redirect all the OPENSSL_malloc calls to secret memory meaning any secret
    keys get automatically protected this way and the other thing it does is
    expose the API to the user who needs it.  We anticipate that a lot of the
    use cases would be like the openssl one: many toolkits that deal with
    secret keys already have special handling for the memory to try to give
    them greater protection, so this would simply be pluggable into the
    toolkits without any need for user application modification.
    
    Hiding secret memory mappings behind an anonymous file allows usage of the
    page cache for tracking pages allocated for the "secret" mappings as well
    as using address_space_operations for e.g.  page migration callbacks.
    
    The anonymous file may be also used implicitly, like hugetlb files, to
    implement mmap(MAP_SECRET) and use the secret memory areas with "native"
    mm ABIs in the future.
    
    Removing of the pages from the direct map may cause its fragmentation on
    architectures that use large pages to map the physical memory which
    affects the system performance.  However, the original Kconfig text for
    CONFIG_DIRECT_GBPAGES said that gigabyte pages in the direct map "...  can
    improve the kernel's performance a tiny bit ..." (commit 00d1c5e
    ("x86: add gbpages switches")) and the recent report [1] showed that "...
    although 1G mappings are a good default choice, there is no compelling
    evidence that it must be the only choice".  Hence, it is sufficient to
    have secretmem disabled by default with the ability of a system
    administrator to enable it at boot time.
    
    In addition, there is also a long term goal to improve management of the
    direct map.
    
    [1] https://lore.kernel.org/linux-mm/213b4567-46ce-f116-9cdf-bbd0c884eb3c@linux.intel.com/
    
    This patch (of 9):
    
    The definition of PMD_PAGE_ORDER denoting the number of base pages in the
    second-level leaf page is already used by DAX and maybe handy in other
    cases as well.
    
    Several architectures already have definition of PMD_ORDER as the size of
    second level page table, so to avoid conflict with these definitions use
    PMD_PAGE_ORDER name and update DAX respectively.
    
    Link: https://lkml.kernel.org/r/20210303162209.8609-1-rppt@kernel.org
    Link: https://lkml.kernel.org/r/20210303162209.8609-2-rppt@kernel.org
    Signed-off-by: Mike Rapoport <rppt@linux.ibm.com>
    Reviewed-by: David Hildenbrand <david@redhat.com>
    Cc: Alexander Viro <viro@zeniv.linux.org.uk>
    Cc: Andy Lutomirski <luto@kernel.org>
    Cc: Arnd Bergmann <arnd@arndb.de>
    Cc: Borislav Petkov <bp@alien8.de>
    Cc: Catalin Marinas <catalin.marinas@arm.com>
    Cc: Christopher Lameter <cl@linux.com>
    Cc: Dan Williams <dan.j.williams@intel.com>
    Cc: Dave Hansen <dave.hansen@linux.intel.com>
    Cc: Elena Reshetova <elena.reshetova@intel.com>
    Cc: "H. Peter Anvin" <hpa@zytor.com>
    Cc: Ingo Molnar <mingo@redhat.com>
    Cc: James Bottomley <jejb@linux.ibm.com>
    Cc: "Kirill A. Shutemov" <kirill@shutemov.name>
    Cc: Matthew Wilcox <willy@infradead.org>
    Cc: Mark Rutland <mark.rutland@arm.com>
    Cc: Michael Kerrisk <mtk.manpages@gmail.com>
    Cc: Palmer Dabbelt <palmer@dabbelt.com>
    Cc: Paul Walmsley <paul.walmsley@sifive.com>
    Cc: Peter Zijlstra <peterz@infradead.org>
    Cc: Rick Edgecombe <rick.p.edgecombe@intel.com>
    Cc: Roman Gushchin <guro@fb.com>
    Cc: Shakeel Butt <shakeelb@google.com>
    Cc: Shuah Khan <shuah@kernel.org>
    Cc: Thomas Gleixner <tglx@linutronix.de>
    Cc: Tycho Andersen <tycho@tycho.ws>
    Cc: Will Deacon <will@kernel.org>
    Cc: Hagen Paul Pfeifer <hagen@jauu.net>
    Cc: Palmer Dabbelt <palmerdabbelt@google.com>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>

    

    rppt authored and sfrothwell committed Mar 19, 2021
    e00d9e3

13. Merge branch 'akpm-current/current'

    

    sfrothwell committed Mar 19, 2021
    bfbaf7f

14. Merge remote-tracking branch 'rust/rust-next' …

    # Conflicts:
    #	Makefile

    

    sfrothwell committed Mar 19, 2021
    c7c4c9b

15. Merge remote-tracking branch 'mhi/mhi-next'

    

    sfrothwell committed Mar 19, 2021
    e81f1e5

16. Merge remote-tracking branch 'fpga/for-next'

    

    sfrothwell committed Mar 19, 2021
    7042873

17. Merge remote-tracking branch 'auxdisplay/auxdisplay'

    

    sfrothwell committed Mar 19, 2021
    30875cb

18. Merge remote-tracking branch 'hyperv/hyperv-next'

    

    sfrothwell committed Mar 19, 2021
    75957da

19. Merge remote-tracking branch 'xarray/main'

    

    sfrothwell committed Mar 19, 2021
    82d6e51

20. Merge remote-tracking branch 'nvmem/for-next'

    

    sfrothwell committed Mar 19, 2021
    b43f7d0

21. Merge remote-tracking branch 'slimbus/for-next' …

    # Conflicts:
    #	drivers/nvmem/Kconfig

    

    sfrothwell committed Mar 19, 2021
    a330eb6

22. Merge remote-tracking branch 'gnss/gnss-next'

    

    sfrothwell committed Mar 19, 2021
    2696059

23. Merge remote-tracking branch 'nvdimm/libnvdimm-for-next'

    

    sfrothwell committed Mar 19, 2021
    2250512

24. Merge remote-tracking branch 'rtc/rtc-next'

    

    sfrothwell committed Mar 19, 2021
    c2aa62f

25. Merge remote-tracking branch 'coresight/next'

    

    sfrothwell committed Mar 19, 2021
    9e9cbfc

26. Merge remote-tracking branch 'livepatching/for-next'

    

    sfrothwell committed Mar 19, 2021
    38de540

27. Merge remote-tracking branch 'pinctrl-renesas/renesas-pinctrl'

    

    sfrothwell committed Mar 19, 2021
    f99be5d

28. Merge remote-tracking branch 'pinctrl-intel/for-next'

    

    sfrothwell committed Mar 19, 2021
    4e12ed6

29. Merge remote-tracking branch 'pinctrl/for-next'

    

    sfrothwell committed Mar 19, 2021
    d21b94d

30. Merge remote-tracking branch 'gpio-intel/for-next' …

    # Conflicts:
    #	drivers/gpio/gpiolib.c

    

    sfrothwell committed Mar 19, 2021
    7e773e3

31. Merge remote-tracking branch 'gpio-brgl/gpio/for-next'

    

    sfrothwell committed Mar 19, 2021
    40d3693

32. Merge remote-tracking branch 'rpmsg/for-next'

    

    sfrothwell committed Mar 19, 2021
    9420137

33. Merge remote-tracking branch 'vhost/linux-next'

    

    sfrothwell committed Mar 19, 2021
    dcc94cb

34. Merge remote-tracking branch 'scsi-mkp/for-next'

    

    sfrothwell committed Mar 19, 2021
    048bc43

35. Merge remote-tracking branch 'scsi/for-next'

    

    sfrothwell committed Mar 19, 2021
    e18d47c