From: Mike Rapoport <rppt@kernel.org> Date: 2020-07-27 16:29:49
From: Mike Rapoport <redacted>
Hi,
This is an implementation of "secret" mappings backed by a file descriptor.
v2 changes:
* Follow Michael's suggestion and name the new system call 'memfd_secret'
* Add kernel-parameters documentation about the boot option
* Fix i386-tinyconfig regression reported by the kbuild bot.
CONFIG_SECRETMEM now depends on !EMBEDDED to disable it on small systems
from one side and still make it available unconditionally on
architectures that support SET_DIRECT_MAP.
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 have desired protection bits set in the user page
table. For instance, current implementation allows uncached mappings.
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, 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
[1] 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.
I've hesitated whether to continue to use new flags to memfd_create() or to
add a new system call and I've decided to use a new system call after I've
started to look into man pages update. There would have been two completely
independent descriptions and I think it would have been very confusing.
Hiding secret memory mappings behind an anonymous file allows (ab)use 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.
As the fragmentation of the direct map was one of the major concerns raised
during the previous postings, I've added an amortizing cache of PMD-size
pages to each file descriptor and an ability to reserve large chunks of the
physical memory at boot time and then use this memory as an allocation pool
for the secret memory areas.
v1: https://lore.kernel.org/lkml/20200720092435.17469-1-rppt@kernel.org/
rfc-v2: https://lore.kernel.org/lkml/20200706172051.19465-1-rppt@kernel.org/
rfc-v1: https://lore.kernel.org/lkml/20200130162340.GA14232@rapoport-lnx/
Mike Rapoport (7):
mm: add definition of PMD_PAGE_ORDER
mmap: make mlock_future_check() global
mm: introduce memfd_secret system call to create "secret" memory areas
arch, mm: wire up memfd_secret system call were relevant
mm: secretmem: use PMD-size pages to amortize direct map fragmentation
mm: secretmem: add ability to reserve memory at boot
mm: secretmem: add ability to reserve memory at boot
.../admin-guide/kernel-parameters.txt | 4 +
arch/arm64/include/asm/unistd32.h | 2 +
arch/arm64/include/uapi/asm/unistd.h | 1 +
arch/riscv/include/asm/unistd.h | 1 +
arch/x86/entry/syscalls/syscall_32.tbl | 1 +
arch/x86/entry/syscalls/syscall_64.tbl | 1 +
fs/dax.c | 10 +-
include/linux/pgtable.h | 3 +
include/linux/syscalls.h | 1 +
include/uapi/asm-generic/unistd.h | 7 +-
include/uapi/linux/magic.h | 1 +
include/uapi/linux/secretmem.h | 9 +
kernel/sys_ni.c | 2 +
mm/Kconfig | 4 +
mm/Makefile | 1 +
mm/internal.h | 3 +
mm/mmap.c | 5 +-
mm/secretmem.c | 453 ++++++++++++++++++
18 files changed, 500 insertions(+), 9 deletions(-)
create mode 100644 include/uapi/linux/secretmem.h
create mode 100644 mm/secretmem.c
--
2.26.2
From: Mike Rapoport <rppt@kernel.org> Date: 2020-07-27 16:29:58
From: Mike Rapoport <redacted>
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.
Signed-off-by: Mike Rapoport <redacted>
---
fs/dax.c | 10 +++++-----
include/linux/pgtable.h | 3 +++
2 files changed, 8 insertions(+), 5 deletions(-)
@@ -28,6 +28,9 @@#define USER_PGTABLES_CEILING 0UL#endif+/* Number of base pages in a second level leaf page */+#define PMD_PAGE_ORDER (PMD_SHIFT - PAGE_SHIFT)+/**Apagetablepagecanbethoughtofanarraylikethis:pXd_t[PTRS_PER_PxD]*
From: Mike Rapoport <rppt@kernel.org> Date: 2020-07-27 16:30:09
From: Mike Rapoport <redacted>
It will be used by the upcoming secret memory implementation.
Signed-off-by: Mike Rapoport <redacted>
---
mm/internal.h | 3 +++
mm/mmap.c | 5 ++---
2 files changed, 5 insertions(+), 3 deletions(-)
From: Mike Rapoport <rppt@kernel.org> Date: 2020-07-27 16:30:18
From: Mike Rapoport <redacted>
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 user will create a file descriptor using the memfd_secret() system call
where flags supplied as a parameter to this system call will define the
desired protection mode for the memory associated with that file
descriptor. Currently there are two protection modes:
* exclusive - the memory area is unmapped from the kernel direct map and it
is present only in the page tables of the owning mm.
* uncached - the memory area is present only in the page tables of the
owning mm and it is mapped there as uncached.
For instance, the following example will create an uncached mapping (error
handling is omitted):
fd = memfd_secret(SECRETMEM_UNCACHED);
ftruncate(fd, MAP_SIZE);
ptr = mmap(NULL, MAP_SIZE, PROT_READ | PROT_WRITE, MAP_SHARED, fd, 0);
Signed-off-by: Mike Rapoport <redacted>
---
include/uapi/linux/magic.h | 1 +
include/uapi/linux/secretmem.h | 9 ++
kernel/sys_ni.c | 2 +
mm/Kconfig | 4 +
mm/Makefile | 1 +
mm/secretmem.c | 266 +++++++++++++++++++++++++++++++++
6 files changed, 283 insertions(+)
create mode 100644 include/uapi/linux/secretmem.h
create mode 100644 mm/secretmem.c
@@ -0,0 +1,266 @@+// SPDX-License-Identifier: GPL-2.0+#include<linux/mm.h>+#include<linux/fs.h>+#include<linux/mount.h>+#include<linux/memfd.h>+#include<linux/bitops.h>+#include<linux/printk.h>+#include<linux/pagemap.h>+#include<linux/syscalls.h>+#include<linux/pseudo_fs.h>+#include<linux/set_memory.h>+#include<linux/sched/signal.h>++#include<uapi/linux/secretmem.h>+#include<uapi/linux/magic.h>++#include<asm/tlbflush.h>++#include"internal.h"++#undef pr_fmt+#define pr_fmt(fmt) "secretmem: " fmt++#define SECRETMEM_MODE_MASK (SECRETMEM_EXCLUSIVE | SECRETMEM_UNCACHED)+#define SECRETMEM_FLAGS_MASK SECRETMEM_MODE_MASK++structsecretmem_ctx{+unsignedintmode;+};++staticstructpage*secretmem_alloc_page(gfp_tgfp)+{+/*+*FIXME:useacacheoflargepagestoreducethedirectmap+*fragmentation+*/+returnalloc_page(gfp);+}++staticvm_fault_tsecretmem_fault(structvm_fault*vmf)+{+structaddress_space*mapping=vmf->vma->vm_file->f_mapping;+structinode*inode=file_inode(vmf->vma->vm_file);+pgoff_toffset=vmf->pgoff;+unsignedlongaddr;+structpage*page;+intret=0;++if(((loff_t)vmf->pgoff<<PAGE_SHIFT)>=i_size_read(inode))+returnvmf_error(-EINVAL);++page=find_get_entry(mapping,offset);+if(!page){+page=secretmem_alloc_page(vmf->gfp_mask);+if(!page)+returnvmf_error(-ENOMEM);++ret=add_to_page_cache(page,mapping,offset,vmf->gfp_mask);+if(unlikely(ret))+gotoerr_put_page;++ret=set_direct_map_invalid_noflush(page);+if(ret)+gotoerr_del_page_cache;++addr=(unsignedlong)page_address(page);+flush_tlb_kernel_range(addr,addr+PAGE_SIZE);++__SetPageUptodate(page);++ret=VM_FAULT_LOCKED;+}++vmf->page=page;+returnret;++err_del_page_cache:+delete_from_page_cache(page);+err_put_page:+put_page(page);+returnvmf_error(ret);+}++staticconststructvm_operations_structsecretmem_vm_ops={+.fault=secretmem_fault,+};++staticintsecretmem_mmap(structfile*file,structvm_area_struct*vma)+{+structsecretmem_ctx*ctx=file->private_data;+unsignedlongmode=ctx->mode;+unsignedlonglen=vma->vm_end-vma->vm_start;++if(!mode)+return-EINVAL;++if((vma->vm_flags&(VM_SHARED|VM_MAYSHARE))==0)+return-EINVAL;++if(mlock_future_check(vma->vm_mm,vma->vm_flags|VM_LOCKED,len))+return-EAGAIN;++switch(mode){+caseSECRETMEM_UNCACHED:+vma->vm_page_prot=pgprot_noncached(vma->vm_page_prot);+fallthrough;+caseSECRETMEM_EXCLUSIVE:+vma->vm_ops=&secretmem_vm_ops;+break;+default:+return-EINVAL;+}++vma->vm_flags|=VM_LOCKED;++return0;+}++conststructfile_operationssecretmem_fops={+.mmap=secretmem_mmap,+};++staticboolsecretmem_isolate_page(structpage*page,isolate_mode_tmode)+{+returnfalse;+}++staticintsecretmem_migratepage(structaddress_space*mapping,+structpage*newpage,structpage*page,+enummigrate_modemode)+{+return-EBUSY;+}++staticvoidsecretmem_freepage(structpage*page)+{+set_direct_map_default_noflush(page);+}++staticconststructaddress_space_operationssecretmem_aops={+.freepage=secretmem_freepage,+.migratepage=secretmem_migratepage,+.isolate_page=secretmem_isolate_page,+};++staticstructvfsmount*secretmem_mnt;++staticstructfile*secretmem_file_create(unsignedlongflags)+{+structfile*file=ERR_PTR(-ENOMEM);+structsecretmem_ctx*ctx;+structinode*inode;++inode=alloc_anon_inode(secretmem_mnt->mnt_sb);+if(IS_ERR(inode))+returnERR_CAST(inode);++ctx=kzalloc(sizeof(*ctx),GFP_KERNEL);+if(!ctx)+gotoerr_free_inode;++file=alloc_file_pseudo(inode,secretmem_mnt,"secretmem",+O_RDWR,&secretmem_fops);+if(IS_ERR(file))+gotoerr_free_ctx;++mapping_set_unevictable(inode->i_mapping);++inode->i_mapping->private_data=ctx;+inode->i_mapping->a_ops=&secretmem_aops;++/* pretend we are a normal file with zero size */+inode->i_mode|=S_IFREG;+inode->i_size=0;++file->private_data=ctx;++ctx->mode=flags&SECRETMEM_MODE_MASK;++returnfile;++err_free_ctx:+kfree(ctx);+err_free_inode:+iput(inode);+returnfile;+}++SYSCALL_DEFINE1(memfd_secret,unsignedlong,flags)+{+structfile*file;+unsignedintmode;+intfd,err;++/* make sure local flags do not confict with global fcntl.h */+BUILD_BUG_ON(SECRETMEM_FLAGS_MASK&O_CLOEXEC);++if(flags&~(SECRETMEM_FLAGS_MASK|O_CLOEXEC))+return-EINVAL;++/* modes are mutually exclusive, only one mode bit should be set */+mode=flags&SECRETMEM_FLAGS_MASK;+if(ffs(mode)!=fls(mode))+return-EINVAL;++fd=get_unused_fd_flags(flags&O_CLOEXEC);+if(fd<0)+returnfd;++file=secretmem_file_create(flags);+if(IS_ERR(file)){+err=PTR_ERR(file);+gotoerr_put_fd;+}++file->f_flags|=O_LARGEFILE;++fd_install(fd,file);+returnfd;++err_put_fd:+put_unused_fd(fd);+returnerr;+}++staticvoidsecretmem_evict_inode(structinode*inode)+{+structsecretmem_ctx*ctx=inode->i_private;++truncate_inode_pages_final(&inode->i_data);+clear_inode(inode);+kfree(ctx);+}++staticconststructsuper_operationssecretmem_super_ops={+.evict_inode=secretmem_evict_inode,+};++staticintsecretmem_init_fs_context(structfs_context*fc)+{+structpseudo_fs_context*ctx=init_pseudo(fc,SECRETMEM_MAGIC);++if(!ctx)+return-ENOMEM;+ctx->ops=&secretmem_super_ops;++return0;+}++staticstructfile_system_typesecretmem_fs={+.name="secretmem",+.init_fs_context=secretmem_init_fs_context,+.kill_sb=kill_anon_super,+};++staticintsecretmem_init(void)+{+intret=0;++secretmem_mnt=kern_mount(&secretmem_fs);+if(IS_ERR(secretmem_mnt))+ret=PTR_ERR(secretmem_mnt);++returnret;+}+fs_initcall(secretmem_init);
Hi Mike,
On Mon, Jul 27, 2020 at 07:29:31PM +0300, Mike Rapoport wrote:
For instance, the following example will create an uncached mapping (error
handling is omitted):
fd = memfd_secret(SECRETMEM_UNCACHED);
ftruncate(fd, MAP_SIZE);
ptr = mmap(NULL, MAP_SIZE, PROT_READ | PROT_WRITE, MAP_SHARED, fd, 0);
I think the uncached mapping is not the right thing for arm/arm64. First
of all, pgprot_noncached() gives us Strongly Ordered (Device memory)
semantics together with not allowing unaligned accesses. I suspect the
semantics are different on x86.
The second, more serious problem, is that I can't find any place where
the caches are flushed for the page mapped on fault. When a page is
allocated, assuming GFP_ZERO, only the caches are guaranteed to be
zeroed. Exposing this subsequently to user space as uncached would allow
the user to read stale data prior to zeroing. The arm64
set_direct_map_default_noflush() doesn't do any cache maintenance.
--
Catalin
From: Mike Rapoport <rppt@kernel.org> Date: 2020-07-30 20:44:30
On Thu, Jul 30, 2020 at 05:22:10PM +0100, Catalin Marinas wrote:
Hi Mike,
On Mon, Jul 27, 2020 at 07:29:31PM +0300, Mike Rapoport wrote:
quoted
For instance, the following example will create an uncached mapping (error
handling is omitted):
fd = memfd_secret(SECRETMEM_UNCACHED);
ftruncate(fd, MAP_SIZE);
ptr = mmap(NULL, MAP_SIZE, PROT_READ | PROT_WRITE, MAP_SHARED, fd, 0);
I think the uncached mapping is not the right thing for arm/arm64. First
of all, pgprot_noncached() gives us Strongly Ordered (Device memory)
semantics together with not allowing unaligned accesses. I suspect the
semantics are different on x86.
Hmm, on x86 it's also Strongly Ordered, but I didn't find any alignment
restrictions. Is there a mode for arm64 that can provide similar
semantics?
Would it make sence to use something like
#define pgprot_uncached(prot) \
__pgprot_modify(prot, PTE_ATTRINDX_MASK, \
PTE_ATTRINDX(MT_NORMAL_NC) | PTE_PXN)
or is it too weak?
The second, more serious problem, is that I can't find any place where
the caches are flushed for the page mapped on fault. When a page is
allocated, assuming GFP_ZERO, only the caches are guaranteed to be
zeroed. Exposing this subsequently to user space as uncached would allow
the user to read stale data prior to zeroing. The arm64
set_direct_map_default_noflush() doesn't do any cache maintenance.
Well, the idea of uncached mappings came from Elena [1] to prevent
possibility of side channels that leak user space memory. So I think
even without cache flushing after the allocation, user space is
protected as all its memory accesses bypass cache so even after the page
is freed there won't be stale data in the cache.
I think that it makes sense to limit SECRETMEM_UNCACHED only for
architectures that define an appropriate protection, e.g.
pgprot_uncahced(). For x86 it can be aliased to pgprot_noncached() and
other architecures can define their versions.
[1] https://lore.kernel.org/lkml/2236FBA76BA1254E88B949DDB74E612BA4EEC0CE@IRSMSX102.ger.corp.intel.com/
--
Sincerely yours,
Mike.
On Thu, Jul 30, 2020 at 11:44:09PM +0300, Mike Rapoport wrote:
On Thu, Jul 30, 2020 at 05:22:10PM +0100, Catalin Marinas wrote:
quoted
On Mon, Jul 27, 2020 at 07:29:31PM +0300, Mike Rapoport wrote:
quoted
For instance, the following example will create an uncached mapping (error
handling is omitted):
fd = memfd_secret(SECRETMEM_UNCACHED);
ftruncate(fd, MAP_SIZE);
ptr = mmap(NULL, MAP_SIZE, PROT_READ | PROT_WRITE, MAP_SHARED, fd, 0);
I think the uncached mapping is not the right thing for arm/arm64. First
of all, pgprot_noncached() gives us Strongly Ordered (Device memory)
semantics together with not allowing unaligned accesses. I suspect the
semantics are different on x86.
Hmm, on x86 it's also Strongly Ordered, but I didn't find any alignment
restrictions. Is there a mode for arm64 that can provide similar
semantics?
Would it make sence to use something like
#define pgprot_uncached(prot) \
__pgprot_modify(prot, PTE_ATTRINDX_MASK, \
PTE_ATTRINDX(MT_NORMAL_NC) | PTE_PXN)
or is it too weak?
Reading Elena's email, that's about preventing speculative loads. While
the arm64 Normal NC is non-cacheable (equivalent to write-combine), a
CPU is allowed to speculatively read from it. A carefully crafted gadget
could leave an imprint on a different part of the cache via speculative
execution based on a value in the secret memory. So IIUC, we want memory
that cannot be speculatively loaded from and that would be Device memory
on arm64 (with the alignment restrictions).
Now, I think we could relax this to Device_GRE. So maybe add a
pgprot_nospec() and allow architectures to define whatever they find
suitable. The exact semantics will be different between architectures.
quoted
The second, more serious problem, is that I can't find any place where
the caches are flushed for the page mapped on fault. When a page is
allocated, assuming GFP_ZERO, only the caches are guaranteed to be
zeroed. Exposing this subsequently to user space as uncached would allow
the user to read stale data prior to zeroing. The arm64
set_direct_map_default_noflush() doesn't do any cache maintenance.
Well, the idea of uncached mappings came from Elena [1] to prevent
possibility of side channels that leak user space memory. So I think
even without cache flushing after the allocation, user space is
protected as all its memory accesses bypass cache so even after the page
is freed there won't be stale data in the cache.
I think that it makes sense to limit SECRETMEM_UNCACHED only for
architectures that define an appropriate protection, e.g.
pgprot_uncahced(). For x86 it can be aliased to pgprot_noncached() and
other architecures can define their versions.
Indeed, though as I said above, maybe use a name that suggests no
speculation since non-cacheable doesn't always guarantee that. Something
like pgprot_nospec() and SECRETMEM_NOSPEC.
However, your implementation still has the problem that such memory must
have the caches flushed before being mapped in user-space, otherwise we
leak other secrets via such pages to the caller. The only generic API we
have in the kernel for such things is the DMA one. If hch doesn't mind,
you could abuse it and call arch_dma_prep_coherent() prior to
set_direct_map_invalid_noflush() (if the mapping is non-cacheable).
--
Catalin
I think the uncached mapping is not the right thing for arm/arm64. First
of all, pgprot_noncached() gives us Strongly Ordered (Device memory)
semantics together with not allowing unaligned accesses. I suspect the
semantics are different on x86.
The second, more serious problem, is that I can't find any place where
the caches are flushed for the page mapped on fault. When a page is
allocated, assuming GFP_ZERO, only the caches are guaranteed to be
zeroed. Exposing this subsequently to user space as uncached would allow
the user to read stale data prior to zeroing. The arm64
set_direct_map_default_noflush() doesn't do any cache maintenance.
It's also worth noting that in a virtual machine this is liable to be
either broken (with a potential loss of coherency if the host has a
cacheable alias as existing KVM hosts have), or pointless (if the host
uses S2FWB to upgrade Stage-1 attribues to cacheable as existing KVM
hosts also have).
I think that trying to avoid the data caches creates many more problems
than it solves, and I don't think there's a strong justification for
trying to support that on arm64 to begin with, so I'd rather entirely
opt-out on supporting SECRETMEM_UNCACHED.
Thanks,
Mark.
I think the uncached mapping is not the right thing for arm/arm64. First
of all, pgprot_noncached() gives us Strongly Ordered (Device memory)
semantics together with not allowing unaligned accesses. I suspect the
semantics are different on x86.
quoted
The second, more serious problem, is that I can't find any place where
the caches are flushed for the page mapped on fault. When a page is
allocated, assuming GFP_ZERO, only the caches are guaranteed to be
zeroed. Exposing this subsequently to user space as uncached would allow
the user to read stale data prior to zeroing. The arm64
set_direct_map_default_noflush() doesn't do any cache maintenance.
It's also worth noting that in a virtual machine this is liable to be
either broken (with a potential loss of coherency if the host has a
cacheable alias as existing KVM hosts have), or pointless (if the host
uses S2FWB to upgrade Stage-1 attribues to cacheable as existing KVM
hosts also have).
I think that trying to avoid the data caches creates many more problems
than it solves, and I don't think there's a strong justification for
trying to support that on arm64 to begin with, so I'd rather entirely
opt-out on supporting SECRETMEM_UNCACHED.
Good point, I forgot the virtualisation aspect. So unless there is a
hypervisor API to unmap it from the host memory, the uncached option
isn't of much use on arm64.
--
Catalin
@@ -360,6 +360,7 @@ 437 common openat2 sys_openat2 438 common pidfd_getfd sys_pidfd_getfd 439 common faccessat2 sys_faccessat2+440 common memfd_secret sys_memfd_secret # # x32-specific system call numbers start at 512 to avoid cache impact
@@ -1005,6 +1005,7 @@ asmlinkage long sys_pidfd_send_signal(int pidfd, int sig,siginfo_t__user*info,unsignedintflags);asmlinkagelongsys_pidfd_getfd(intpidfd,intfd,unsignedintflags);+asmlinkagelongsys_memfd_secret(unsignedlongflags);/**Architecture-specificsystemcalls
On Mon, Jul 27, 2020 at 6:30 PM Mike Rapoport [off-list ref] wrote:
From: Mike Rapoport <redacted>
Wire up memfd_secret system call on architectures that define
ARCH_HAS_SET_DIRECT_MAP, namely arm64, risc-v and x86.
Signed-off-by: Mike Rapoport <redacted>
Acked-by: Palmer Dabbelt <redacted>
From: Mike Rapoport <rppt@kernel.org> Date: 2020-07-27 16:30:36
From: Mike Rapoport <redacted>
Removing a PAGE_SIZE page from the direct map every time such page is
allocated for a secret memory mapping will cause severe fragmentation of
the direct map. This fragmentation can be reduced by using PMD-size pages
as a pool for small pages for secret memory mappings.
Add a gen_pool per secretmem inode and lazily populate this pool with
PMD-size pages.
Signed-off-by: Mike Rapoport <redacted>
---
mm/secretmem.c | 107 ++++++++++++++++++++++++++++++++++++++++---------
1 file changed, 88 insertions(+), 19 deletions(-)
From: Mike Rapoport <rppt@kernel.org> Date: 2020-07-27 16:30:44
From: Mike Rapoport <redacted>
Taking pages out from the direct map and bringing them back may create
undesired fragmentation and usage of the smaller pages in the direct
mapping of the physical memory.
This can be avoided if a significantly large area of the physical memory
would be reserved for secretmem purposes at boot time.
Add ability to reserve physical memory for secretmem at boot time using
"secretmem" kernel parameter and then use that reserved memory as a global
pool for secret memory needs.
Signed-off-by: Mike Rapoport <redacted>
---
mm/secretmem.c | 134 ++++++++++++++++++++++++++++++++++++++++++++++---
1 file changed, 126 insertions(+), 8 deletions(-)
From: Mike Rapoport <rppt@kernel.org> Date: 2020-07-27 16:30:51
From: Mike Rapoport <redacted>
Taking pages out from the direct map and bringing them back may create
undesired fragmentation and usage of the smaller pages in the direct
mapping of the physical memory.
This can be avoided if a significantly large area of the physical memory
would be reserved for secretmem purposes at boot time.
Add ability to reserve physical memory for secretmem at boot time using
"secretmem" kernel parameter and then use that reserved memory as a global
pool for secret memory needs.
Signed-off-by: Mike Rapoport <redacted>
---
Documentation/admin-guide/kernel-parameters.txt | 4 ++++
1 file changed, 4 insertions(+)
@@ -4548,6 +4548,10 @@ Format: integer between 0 and 10 Default is 0.+ secretmem=n[KMG]+ [KNL,BOOT] Reserve specified amount of memory to+ back mappings of secret memory.+ skew_tick= [KNL] Offset the periodic timer tick per cpu to mitigate xtime_lock contention on larger systems, and/or RCU lock contention on all systems with CONFIG_MAXSMP set.
From: Mike Rapoport <rppt@kernel.org> Date: 2020-07-27 17:11:20
Oops, something went wrong with the rebase, this should have been
squashed into the previous patch...
On Mon, Jul 27, 2020 at 07:29:35PM +0300, Mike Rapoport wrote:
quoted hunk
From: Mike Rapoport <redacted>
Taking pages out from the direct map and bringing them back may create
undesired fragmentation and usage of the smaller pages in the direct
mapping of the physical memory.
This can be avoided if a significantly large area of the physical memory
would be reserved for secretmem purposes at boot time.
Add ability to reserve physical memory for secretmem at boot time using
"secretmem" kernel parameter and then use that reserved memory as a global
pool for secret memory needs.
Signed-off-by: Mike Rapoport <redacted>
---
Documentation/admin-guide/kernel-parameters.txt | 4 ++++
1 file changed, 4 insertions(+)
@@ -4548,6 +4548,10 @@ Format: integer between 0 and 10 Default is 0.+ secretmem=n[KMG]+ [KNL,BOOT] Reserve specified amount of memory to+ back mappings of secret memory.+ skew_tick= [KNL] Offset the periodic timer tick per cpu to mitigate xtime_lock contention on larger systems, and/or RCU lock contention on all systems with CONFIG_MAXSMP set.