On Thu, 2021-05-13 at 21:47 +0300, Mike Rapoport wrote: > From: Mike Rapoport <rppt@xxxxxxxxxxxxx> > > Hi, > > @Andrew, this is based on v5.13-rc1, I can rebase whatever way you > prefer. > > 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. > > It's designed to provide the following protections: > > * Enhanced protection (in conjunction with all the other in-kernel > attack prevention systems) against ROP attacks. Seceretmem makes > "simple" > ROP insufficient to perform exfiltration, which increases the > required > complexity of the attack. Along with other protections like the > kernel > stack size limit and address space layout randomization which make > finding > gadgets is really hard, absence of any in-kernel primitive for > accessing > secret memory means the one gadget ROP attack can't work. Since the > only > way to access secret memory is to reconstruct the missing mapping > entry, > the attacker has to recover the physical page and insert a PTE > pointing to > it in the kernel and then retrieve the contents. That takes at least > three > gadgets which is a level of difficulty beyond most standard attacks. > > * Prevent cross-process secret userspace memory exposures. Once the > secret > memory is allocated, the user can't accidentally pass it into the > kernel to > be transmitted somewhere. The secreremem pages cannot be accessed via > the > direct map and they are disallowed in GUP. > > * Harden against exploited kernel flaws. In order to access > secretmem, a > kernel-side attack would need to either walk the page tables and > create new > ones, or spawn a new privileged uiserspace process to perform secrets > exfiltration using ptrace. > > 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 00d1c5e05736 > ("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@xxxxxxxxxxxxxxx/ > > v19: > * block /dev/mem mmap access, per David > * disallow mmap/mprotect with PROT_EXEC, per Kees > * simplify return in page_is_secretmem(), per Matthew > * use unsigned int for syscall falgs, per Yury > > v18: > https://lore.kernel.org/lkml/20210303162209.8609-1-rppt@xxxxxxxxxx > * rebase on v5.12-rc1 > * merge kfence fix into the original patch > * massage commit message of the patch introducing the memfd_secret > syscall > > v17: > https://lore.kernel.org/lkml/20210208084920.2884-1-rppt@xxxxxxxxxx > * Remove pool of large pages backing secretmem allocations, per > Michal Hocko > * Add secretmem pages to unevictable LRU, per Michal Hocko > * Use GFP_HIGHUSER as secretmem mapping mask, per Michal Hocko > * Make secretmem an opt-in feature that is disabled by default > > v16: > https://lore.kernel.org/lkml/20210121122723.3446-1-rppt@xxxxxxxxxx > * Fix memory leak intorduced in v15 > * Clean the data left from previous page user before handing the page > to > the userspace > > v15: > https://lore.kernel.org/lkml/20210120180612.1058-1-rppt@xxxxxxxxxx > * Add riscv/Kconfig update to disable set_memory operations for nommu > builds (patch 3) > * Update the code around add_to_page_cache() per Matthew's comments > (patches 6,7) > * Add fixups for build/checkpatch errors discovered by CI systems > > Older history: > v14: > https://lore.kernel.org/lkml/20201203062949.5484-1-rppt@xxxxxxxxxx > v13: > https://lore.kernel.org/lkml/20201201074559.27742-1-rppt@xxxxxxxxxx > v12: > https://lore.kernel.org/lkml/20201125092208.12544-1-rppt@xxxxxxxxxx > v11: > https://lore.kernel.org/lkml/20201124092556.12009-1-rppt@xxxxxxxxxx > v10: > https://lore.kernel.org/lkml/20201123095432.5860-1-rppt@xxxxxxxxxx > v9: > https://lore.kernel.org/lkml/20201117162932.13649-1-rppt@xxxxxxxxxx > v8: > https://lore.kernel.org/lkml/20201110151444.20662-1-rppt@xxxxxxxxxx > v7: > https://lore.kernel.org/lkml/20201026083752.13267-1-rppt@xxxxxxxxxx > v6: > https://lore.kernel.org/lkml/20200924132904.1391-1-rppt@xxxxxxxxxx > v5: > https://lore.kernel.org/lkml/20200916073539.3552-1-rppt@xxxxxxxxxx > v4: > https://lore.kernel.org/lkml/20200818141554.13945-1-rppt@xxxxxxxxxx > v3: > https://lore.kernel.org/lkml/20200804095035.18778-1-rppt@xxxxxxxxxx > v2: > https://lore.kernel.org/lkml/20200727162935.31714-1-rppt@xxxxxxxxxx > v1: > https://lore.kernel.org/lkml/20200720092435.17469-1-rppt@xxxxxxxxxx > rfc-v2: > https://lore.kernel.org/lkml/20200706172051.19465-1-rppt@xxxxxxxxxx/ > rfc-v1: > https://lore.kernel.org/lkml/20200130162340.GA14232@rapoport-lnx/ > rfc-v0: > https://lore.kernel.org/lkml/1572171452-7958-1-git-send-email-rppt@xxxxxxxxxx/ > > Mike Rapoport (8): > mmap: make mlock_future_check() global > riscv/Kconfig: make direct map manipulation options depend on MMU > set_memory: allow set_direct_map_*_noflush() for multiple pages > set_memory: allow querying whether set_direct_map_*() is actually > enabled > mm: introduce memfd_secret system call to create "secret" memory > areas > PM: hibernate: disable when there are active secretmem users > arch, mm: wire up memfd_secret system call where relevant > secretmem: test: add basic selftest for memfd_secret(2) > > arch/arm64/include/asm/Kbuild | 1 - > arch/arm64/include/asm/cacheflush.h | 6 - > arch/arm64/include/asm/kfence.h | 2 +- > arch/arm64/include/asm/set_memory.h | 17 ++ > arch/arm64/include/uapi/asm/unistd.h | 1 + > arch/arm64/kernel/machine_kexec.c | 1 + > arch/arm64/mm/mmu.c | 6 +- > arch/arm64/mm/pageattr.c | 23 +- > arch/riscv/Kconfig | 4 +- > arch/riscv/include/asm/set_memory.h | 4 +- > arch/riscv/include/asm/unistd.h | 1 + > arch/riscv/mm/pageattr.c | 8 +- > arch/x86/entry/syscalls/syscall_32.tbl | 1 + > arch/x86/entry/syscalls/syscall_64.tbl | 1 + > arch/x86/include/asm/set_memory.h | 4 +- > arch/x86/mm/pat/set_memory.c | 8 +- > drivers/char/mem.c | 4 + > include/linux/secretmem.h | 54 ++++ > include/linux/set_memory.h | 16 +- > include/linux/syscalls.h | 1 + > include/uapi/asm-generic/unistd.h | 7 +- > include/uapi/linux/magic.h | 1 + > kernel/power/hibernate.c | 5 +- > kernel/power/snapshot.c | 4 +- > kernel/sys_ni.c | 2 + > mm/Kconfig | 4 + > mm/Makefile | 1 + > mm/gup.c | 12 + > mm/internal.h | 3 + > mm/mlock.c | 3 +- > mm/mmap.c | 5 +- > mm/secretmem.c | 254 +++++++++++++++++++ > mm/vmalloc.c | 5 +- > scripts/checksyscalls.sh | 4 + > tools/testing/selftests/vm/.gitignore | 1 + > tools/testing/selftests/vm/Makefile | 3 +- > tools/testing/selftests/vm/memfd_secret.c | 296 > ++++++++++++++++++++++ > tools/testing/selftests/vm/run_vmtests.sh | 17 ++ > 38 files changed, 744 insertions(+), 46 deletions(-) > create mode 100644 arch/arm64/include/asm/set_memory.h > create mode 100644 include/linux/secretmem.h > create mode 100644 mm/secretmem.c > create mode 100644 tools/testing/selftests/vm/memfd_secret.c > > > base-commit: 6efb943b8616ec53a5e444193dccf1af9ad627b5 For the series: Acked-by: James Bottomley <James.Bottomley@xxxxxxxxxxxxxxxxxxxxx> James
