From: Mike Rapoport <rppt@kernel.org> Date: 2020-08-18 14:16:31
From: Mike Rapoport <redacted>
Hi,
This is an implementation of "secret" mappings backed by a file descriptor.
v4 changes:
* rebase on v5.9-rc1
* Do not redefine PMD_PAGE_ORDER in fs/dax.c, thanks Kirill
* Make secret mappings exclusive by default and only require flags to
memfd_secret() system call for uncached mappings, thanks again Kirill :)
v3 changes:
* Squash kernel-parameters.txt update into the commit that added the
command line option.
* Make uncached mode explicitly selectable by architectures. For now enable
it only on x86.
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.
v3: https://lore.kernel.org/lkml/20200804095035.18778-1-rppt@kernel.org
v2: https://lore.kernel.org/lkml/20200727162935.31714-1-rppt@kernel.org
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 (6):
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
arch/Kconfig | 7 +
arch/arm64/include/asm/unistd.h | 2 +-
arch/arm64/include/asm/unistd32.h | 2 +
arch/arm64/include/uapi/asm/unistd.h | 1 +
arch/riscv/include/asm/unistd.h | 1 +
arch/x86/Kconfig | 1 +
arch/x86/entry/syscalls/syscall_32.tbl | 1 +
arch/x86/entry/syscalls/syscall_64.tbl | 1 +
fs/dax.c | 11 +-
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 | 8 +
kernel/sys_ni.c | 2 +
mm/Kconfig | 4 +
mm/Makefile | 1 +
mm/internal.h | 3 +
mm/mmap.c | 5 +-
mm/secretmem.c | 451 +++++++++++++++++++++++++
20 files changed, 501 insertions(+), 12 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-08-18 14:16:35
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 | 11 ++++-------
include/linux/pgtable.h | 3 +++
2 files changed, 7 insertions(+), 7 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-08-18 14:16:46
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-08-18 14:16:58
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.
The "exclusive" mode is enabled implicitly and it is the default mode for
memfd_secret().
The "uncached" mode requires architecture support and an architecture
should opt-in for this mode using HAVE_SECRETMEM_UNCACHED configuration
option.
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>
---
arch/Kconfig | 7 +
arch/x86/Kconfig | 1 +
include/uapi/linux/magic.h | 1 +
include/uapi/linux/secretmem.h | 8 +
kernel/sys_ni.c | 2 +
mm/Kconfig | 4 +
mm/Makefile | 1 +
mm/secretmem.c | 264 +++++++++++++++++++++++++++++++++
8 files changed, 288 insertions(+)
create mode 100644 include/uapi/linux/secretmem.h
create mode 100644 mm/secretmem.c
@@ -0,0 +1,264 @@+// SPDX-License-Identifier: GPL-2.0+/*+*CopyrightIBMCorporation,2020+*+*Author:MikeRapoport<rppt@linux.ibm.com>+*/++#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++/*+*Secretmemoryareasarealwaysexclusivetoowningmmandtheyare+*removedfromthedirectmap.+*/+#ifdef CONFIG_HAVE_SECRETMEM_UNCACHED+#define SECRETMEM_MODE_MASK (SECRETMEM_UNCACHED)+#else+#define SECRETMEM_MODE_MASK (0x0)+#endif++#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;+unsignedlonglen=vma->vm_end-vma->vm_start;++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;++if(ctx->mode&SECRETMEM_UNCACHED)+vma->vm_page_prot=pgprot_noncached(vma->vm_page_prot);++vma->vm_ops=&secretmem_vm_ops;+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;+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;++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);
@@ -361,6 +361,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
@@ -1006,6 +1006,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
From: Mike Rapoport <rppt@kernel.org> Date: 2020-08-18 14:17:40
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-08-18 14:17:49
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: David Hildenbrand <hidden> Date: 2020-08-19 10:48:55
On 18.08.20 16:15, Mike Rapoport wrote:
From: Mike Rapoport <redacted>
Hi,
This is an implementation of "secret" mappings backed by a file descriptor.
v4 changes:
* rebase on v5.9-rc1
* Do not redefine PMD_PAGE_ORDER in fs/dax.c, thanks Kirill
* Make secret mappings exclusive by default and only require flags to
memfd_secret() system call for uncached mappings, thanks again Kirill :)
v3 changes:
* Squash kernel-parameters.txt update into the commit that added the
command line option.
* Make uncached mode explicitly selectable by architectures. For now enable
it only on x86.
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.
Just a general question. I assume such pages (where the direct mapping
was changed) cannot get migrated - I can spot a simple alloc_page(). So
essentially a process can just allocate a whole bunch of memory that is
unmovable, correct? Is there any limit? Is it properly accounted towards
the process (memctl) ?
--
Thanks,
David / dhildenb
From: David Hildenbrand <hidden> Date: 2020-08-19 10:49:30
On 18.08.20 16:15, Mike Rapoport wrote:
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.
Wouldn't something like CMA be the better fit? Just wondering. Then, the
memory can actually be reused for something else while not needed.
From: Mike Rapoport <rppt@kernel.org> Date: 2020-08-19 11:43:08
On Wed, Aug 19, 2020 at 12:47:54PM +0200, David Hildenbrand wrote:
On 18.08.20 16:15, Mike Rapoport wrote:
quoted
From: Mike Rapoport <redacted>
Hi,
This is an implementation of "secret" mappings backed by a file descriptor.
v4 changes:
* rebase on v5.9-rc1
* Do not redefine PMD_PAGE_ORDER in fs/dax.c, thanks Kirill
* Make secret mappings exclusive by default and only require flags to
memfd_secret() system call for uncached mappings, thanks again Kirill :)
v3 changes:
* Squash kernel-parameters.txt update into the commit that added the
command line option.
* Make uncached mode explicitly selectable by architectures. For now enable
it only on x86.
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.
Just a general question. I assume such pages (where the direct mapping
was changed) cannot get migrated - I can spot a simple alloc_page(). So
essentially a process can just allocate a whole bunch of memory that is
unmovable, correct? Is there any limit? Is it properly accounted towards
the process (memctl) ?
The memory as accounted in the same way like with mlock(), so normal
user won't be able to allocate more than RLIMIT_MEMLOCK.
From: Mike Rapoport <rppt@kernel.org> Date: 2020-08-19 11:56:40
On Wed, Aug 19, 2020 at 12:49:05PM +0200, David Hildenbrand wrote:
On 18.08.20 16:15, Mike Rapoport wrote:
quoted
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.
Wouldn't something like CMA be the better fit? Just wondering. Then, the
memory can actually be reused for something else while not needed.
The memory allocated as secret is removed from the direct map and the
boot time reservation is intended to reduce direct map fragmentatioan
and to avoid splitting 1G pages there. So with CMA I'd still need to
allocate 1G chunks for this and once 1G page is dropped from the direct
map it still cannot be reused for anything else until it is freed.
I could use CMA to do the boot time reservation, but doing the
reservesion directly seemed simpler and more explicit to me.
From: David Hildenbrand <hidden> Date: 2020-08-19 12:06:39
On 19.08.20 13:42, Mike Rapoport wrote:
On Wed, Aug 19, 2020 at 12:47:54PM +0200, David Hildenbrand wrote:
quoted
On 18.08.20 16:15, Mike Rapoport wrote:
quoted
From: Mike Rapoport <redacted>
Hi,
This is an implementation of "secret" mappings backed by a file descriptor.
v4 changes:
* rebase on v5.9-rc1
* Do not redefine PMD_PAGE_ORDER in fs/dax.c, thanks Kirill
* Make secret mappings exclusive by default and only require flags to
memfd_secret() system call for uncached mappings, thanks again Kirill :)
v3 changes:
* Squash kernel-parameters.txt update into the commit that added the
command line option.
* Make uncached mode explicitly selectable by architectures. For now enable
it only on x86.
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.
Just a general question. I assume such pages (where the direct mapping
was changed) cannot get migrated - I can spot a simple alloc_page(). So
essentially a process can just allocate a whole bunch of memory that is
unmovable, correct? Is there any limit? Is it properly accounted towards
the process (memctl) ?
The memory as accounted in the same way like with mlock(), so normal
user won't be able to allocate more than RLIMIT_MEMLOCK.
Okay, thanks. AFAIU the difference to mlock() is that the pages here are
not movable, fragment memory, and limit compaction. Hm.
--
Thanks,
David / dhildenb
From: David Hildenbrand <hidden> Date: 2020-08-19 12:11:08
On 19.08.20 13:53, Mike Rapoport wrote:
On Wed, Aug 19, 2020 at 12:49:05PM +0200, David Hildenbrand wrote:
quoted
On 18.08.20 16:15, Mike Rapoport wrote:
quoted
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.
Wouldn't something like CMA be the better fit? Just wondering. Then, the
memory can actually be reused for something else while not needed.
The memory allocated as secret is removed from the direct map and the
boot time reservation is intended to reduce direct map fragmentatioan
and to avoid splitting 1G pages there. So with CMA I'd still need to
allocate 1G chunks for this and once 1G page is dropped from the direct
map it still cannot be reused for anything else until it is freed.
I could use CMA to do the boot time reservation, but doing the
reservesion directly seemed simpler and more explicit to me.
Well, using CMA would give you the possibility to let the memory be used
for other purposes until you decide it's the right time to take it +
remove the direct mapping etc.
I wonder if a sane approach would be to require to allocate a pool
during boot and only take pages ever from that pool. That would avoid
spilling many unmovable pages all over the place, locally limiting them
to your area here.
--
Thanks,
David / dhildenb
From: Mike Rapoport <rppt@kernel.org> Date: 2020-08-19 17:34:09
On Wed, Aug 19, 2020 at 02:10:43PM +0200, David Hildenbrand wrote:
On 19.08.20 13:53, Mike Rapoport wrote:
quoted
On Wed, Aug 19, 2020 at 12:49:05PM +0200, David Hildenbrand wrote:
quoted
On 18.08.20 16:15, Mike Rapoport wrote:
quoted
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.
Wouldn't something like CMA be the better fit? Just wondering. Then, the
memory can actually be reused for something else while not needed.
The memory allocated as secret is removed from the direct map and the
boot time reservation is intended to reduce direct map fragmentatioan
and to avoid splitting 1G pages there. So with CMA I'd still need to
allocate 1G chunks for this and once 1G page is dropped from the direct
map it still cannot be reused for anything else until it is freed.
I could use CMA to do the boot time reservation, but doing the
reservesion directly seemed simpler and more explicit to me.
Well, using CMA would give you the possibility to let the memory be used
for other purposes until you decide it's the right time to take it +
remove the direct mapping etc.
I still can't say I follow you here. If I reseve a CMA area as a pool
for secret memory 1G pages, it is still reserved and it still cannot be
used for other purposes, right?
I wonder if a sane approach would be to require to allocate a pool
during boot and only take pages ever from that pool. That would avoid
spilling many unmovable pages all over the place, locally limiting them
to your area here.
That's what I tried to implement. The pool reserved at boot time is in a
way similar to booting with mem=X and then splitting the remaining
memory between the VMs.
In this case, the memory reserved at boot is never in the direct map and
allocations from such pool will not cause fragmentation.
From: David Hildenbrand <hidden> Date: 2020-08-19 17:46:01
On 19.08.20 19:33, Mike Rapoport wrote:
On Wed, Aug 19, 2020 at 02:10:43PM +0200, David Hildenbrand wrote:
quoted
On 19.08.20 13:53, Mike Rapoport wrote:
quoted
On Wed, Aug 19, 2020 at 12:49:05PM +0200, David Hildenbrand wrote:
quoted
On 18.08.20 16:15, Mike Rapoport wrote:
quoted
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.
Wouldn't something like CMA be the better fit? Just wondering. Then, the
memory can actually be reused for something else while not needed.
The memory allocated as secret is removed from the direct map and the
boot time reservation is intended to reduce direct map fragmentatioan
and to avoid splitting 1G pages there. So with CMA I'd still need to
allocate 1G chunks for this and once 1G page is dropped from the direct
map it still cannot be reused for anything else until it is freed.
I could use CMA to do the boot time reservation, but doing the
reservesion directly seemed simpler and more explicit to me.
Well, using CMA would give you the possibility to let the memory be used
for other purposes until you decide it's the right time to take it +
remove the direct mapping etc.
I still can't say I follow you here. If I reseve a CMA area as a pool
for secret memory 1G pages, it is still reserved and it still cannot be
used for other purposes, right?
So, AFAIK, if you create a CMA pool it can be used for any MOVABLE
allocations (similar to ZONE_MOVABLE) until you actually allocate CMA
memory from that region. Other allocations on that are will then be
migrated away (using alloc_contig_range()).
For example, if you have a 1~GiB CMA area, you could allocate 4~MB pages
from that CMA area on demand (removing the direct mapping, etc ..), and
free when no longer needed (instantiating the direct mapping). The free
memory in that area could used for MOVABLE allocations.
Please let me know if I am missing something important.
--
Thanks,
David / dhildenb
From: Mike Rapoport <rppt@kernel.org> Date: 2020-08-20 15:52:49
On Wed, Aug 19, 2020 at 07:45:29PM +0200, David Hildenbrand wrote:
On 19.08.20 19:33, Mike Rapoport wrote:
quoted
On Wed, Aug 19, 2020 at 02:10:43PM +0200, David Hildenbrand wrote:
quoted
On 19.08.20 13:53, Mike Rapoport wrote:
quoted
On Wed, Aug 19, 2020 at 12:49:05PM +0200, David Hildenbrand wrote:
quoted
On 18.08.20 16:15, Mike Rapoport wrote:
quoted
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.
Wouldn't something like CMA be the better fit? Just wondering. Then, the
memory can actually be reused for something else while not needed.
The memory allocated as secret is removed from the direct map and the
boot time reservation is intended to reduce direct map fragmentatioan
and to avoid splitting 1G pages there. So with CMA I'd still need to
allocate 1G chunks for this and once 1G page is dropped from the direct
map it still cannot be reused for anything else until it is freed.
I could use CMA to do the boot time reservation, but doing the
reservesion directly seemed simpler and more explicit to me.
Well, using CMA would give you the possibility to let the memory be used
for other purposes until you decide it's the right time to take it +
remove the direct mapping etc.
I still can't say I follow you here. If I reseve a CMA area as a pool
for secret memory 1G pages, it is still reserved and it still cannot be
used for other purposes, right?
So, AFAIK, if you create a CMA pool it can be used for any MOVABLE
allocations (similar to ZONE_MOVABLE) until you actually allocate CMA
memory from that region. Other allocations on that are will then be
migrated away (using alloc_contig_range()).
For example, if you have a 1~GiB CMA area, you could allocate 4~MB pages
from that CMA area on demand (removing the direct mapping, etc ..), and
free when no longer needed (instantiating the direct mapping). The free
memory in that area could used for MOVABLE allocations.
The boot time resrvation is intended to avoid splitting 1G pages in the
direct map. Without the boot time reservation, we maintain a pool of 2M
pages so the 1G pages are split and 2M pages remain unsplit.
If I scale your example to match the requirement to avoid splitting 1G
pages in the direct map, that would mean creating a CMA area of several
tens of gigabytes and then doing cma_alloc() of 1G each time we need to
refill the secretmem pool.
It is quite probable that we won't be able to get 1G from CMA after the
system worked for some time.
With boot time reservation we won't need physcally contiguous 1G to
satisfy smaller allocation requests for secretmem because we don't need
to maintain 1G mappings in the secretmem pool.
That said, I believe the addition of the boot time reservation, either
direct or with CMA, can be added as an incrememntal patch after the
"core" functionality is merged.
Please let me know if I am missing something important.
--
Thanks,
David / dhildenb
From: Mike Rapoport <rppt@kernel.org> Date: 2020-08-26 11:03:09
Any comments on this?
On Tue, Aug 18, 2020 at 05:15:48PM +0300, Mike Rapoport wrote:
From: Mike Rapoport <redacted>
Hi,
This is an implementation of "secret" mappings backed by a file descriptor.
v4 changes:
* rebase on v5.9-rc1
* Do not redefine PMD_PAGE_ORDER in fs/dax.c, thanks Kirill
* Make secret mappings exclusive by default and only require flags to
memfd_secret() system call for uncached mappings, thanks again Kirill :)
v3 changes:
* Squash kernel-parameters.txt update into the commit that added the
command line option.
* Make uncached mode explicitly selectable by architectures. For now enable
it only on x86.
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.
v3: https://lore.kernel.org/lkml/20200804095035.18778-1-rppt@kernel.org
v2: https://lore.kernel.org/lkml/20200727162935.31714-1-rppt@kernel.org
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 (6):
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
arch/Kconfig | 7 +
arch/arm64/include/asm/unistd.h | 2 +-
arch/arm64/include/asm/unistd32.h | 2 +
arch/arm64/include/uapi/asm/unistd.h | 1 +
arch/riscv/include/asm/unistd.h | 1 +
arch/x86/Kconfig | 1 +
arch/x86/entry/syscalls/syscall_32.tbl | 1 +
arch/x86/entry/syscalls/syscall_64.tbl | 1 +
fs/dax.c | 11 +-
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 | 8 +
kernel/sys_ni.c | 2 +
mm/Kconfig | 4 +
mm/Makefile | 1 +
mm/internal.h | 3 +
mm/mmap.c | 5 +-
mm/secretmem.c | 451 +++++++++++++++++++++++++
20 files changed, 501 insertions(+), 12 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-09-03 07:46:47
Any updates on this?
On Tue, Aug 18, 2020 at 05:15:48PM +0300, Mike Rapoport wrote:
From: Mike Rapoport <redacted>
Hi,
This is an implementation of "secret" mappings backed by a file descriptor.
v4 changes:
* rebase on v5.9-rc1
* Do not redefine PMD_PAGE_ORDER in fs/dax.c, thanks Kirill
* Make secret mappings exclusive by default and only require flags to
memfd_secret() system call for uncached mappings, thanks again Kirill :)
v3 changes:
* Squash kernel-parameters.txt update into the commit that added the
command line option.
* Make uncached mode explicitly selectable by architectures. For now enable
it only on x86.
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.
v3: https://lore.kernel.org/lkml/20200804095035.18778-1-rppt@kernel.org
v2: https://lore.kernel.org/lkml/20200727162935.31714-1-rppt@kernel.org
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 (6):
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
arch/Kconfig | 7 +
arch/arm64/include/asm/unistd.h | 2 +-
arch/arm64/include/asm/unistd32.h | 2 +
arch/arm64/include/uapi/asm/unistd.h | 1 +
arch/riscv/include/asm/unistd.h | 1 +
arch/x86/Kconfig | 1 +
arch/x86/entry/syscalls/syscall_32.tbl | 1 +
arch/x86/entry/syscalls/syscall_64.tbl | 1 +
fs/dax.c | 11 +-
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 | 8 +
kernel/sys_ni.c | 2 +
mm/Kconfig | 4 +
mm/Makefile | 1 +
mm/internal.h | 3 +
mm/mmap.c | 5 +-
mm/secretmem.c | 451 +++++++++++++++++++++++++
20 files changed, 501 insertions(+), 12 deletions(-)
create mode 100644 include/uapi/linux/secretmem.h
create mode 100644 mm/secretmem.c
--
2.26.2
From: David Hildenbrand <hidden> Date: 2020-09-08 09:09:49
On 20.08.20 17:52, Mike Rapoport wrote:
On Wed, Aug 19, 2020 at 07:45:29PM +0200, David Hildenbrand wrote:
quoted
On 19.08.20 19:33, Mike Rapoport wrote:
quoted
On Wed, Aug 19, 2020 at 02:10:43PM +0200, David Hildenbrand wrote:
quoted
On 19.08.20 13:53, Mike Rapoport wrote:
quoted
On Wed, Aug 19, 2020 at 12:49:05PM +0200, David Hildenbrand wrote:
quoted
On 18.08.20 16:15, Mike Rapoport wrote:
quoted
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.
Wouldn't something like CMA be the better fit? Just wondering. Then, the
memory can actually be reused for something else while not needed.
The memory allocated as secret is removed from the direct map and the
boot time reservation is intended to reduce direct map fragmentatioan
and to avoid splitting 1G pages there. So with CMA I'd still need to
allocate 1G chunks for this and once 1G page is dropped from the direct
map it still cannot be reused for anything else until it is freed.
I could use CMA to do the boot time reservation, but doing the
reservesion directly seemed simpler and more explicit to me.
Well, using CMA would give you the possibility to let the memory be used
for other purposes until you decide it's the right time to take it +
remove the direct mapping etc.
I still can't say I follow you here. If I reseve a CMA area as a pool
for secret memory 1G pages, it is still reserved and it still cannot be
used for other purposes, right?
So, AFAIK, if you create a CMA pool it can be used for any MOVABLE
allocations (similar to ZONE_MOVABLE) until you actually allocate CMA
memory from that region. Other allocations on that are will then be
migrated away (using alloc_contig_range()).
For example, if you have a 1~GiB CMA area, you could allocate 4~MB pages
from that CMA area on demand (removing the direct mapping, etc ..), and
free when no longer needed (instantiating the direct mapping). The free
memory in that area could used for MOVABLE allocations.
The boot time resrvation is intended to avoid splitting 1G pages in the
direct map. Without the boot time reservation, we maintain a pool of 2M
pages so the 1G pages are split and 2M pages remain unsplit.
If I scale your example to match the requirement to avoid splitting 1G
pages in the direct map, that would mean creating a CMA area of several
tens of gigabytes and then doing cma_alloc() of 1G each time we need to
refill the secretmem pool.
It is quite probable that we won't be able to get 1G from CMA after the
system worked for some time.
Why? It should only contain movable pages, and if that is not the case,
it's a bug we have to fix. It should behave just as ZONE_MOVABLE.
(although I agree that in corner cases, alloc_contig_pages() might
temporarily fail on some chunks - e.g., with long/short-term page
pinnings - in contrast to memory offlining, it won't retry forever)
With boot time reservation we won't need physcally contiguous 1G to
satisfy smaller allocation requests for secretmem because we don't need
to maintain 1G mappings in the secretmem pool.
You can allocate within your CMA area however you want - doesn't need to
be whole gigabytes in case there is no need for it.
Again, the big benefit of CMA is that the reserved memory can be reused
for other purpose while nobody is actually making use of it.
That said, I believe the addition of the boot time reservation, either
direct or with CMA, can be added as an incrememntal patch after the
"core" functionality is merged.
I am not convinced that we want to let random processes to do
alloc_pages() in the range of tens of gigabytes. It's not just mlocked
memory. I prefer either using CMA or relying on the boot time
reservations. But let's see if there are other opinions and people just
don't care.
Having that said, I have no further comments.
--
Thanks,
David / dhildenb
From: Mike Rapoport <rppt@kernel.org> Date: 2020-09-08 16:57:41
Hi David,
On Tue, Sep 08, 2020 at 11:09:19AM +0200, David Hildenbrand wrote:
On 20.08.20 17:52, Mike Rapoport wrote:
quoted
On Wed, Aug 19, 2020 at 07:45:29PM +0200, David Hildenbrand wrote:
quoted
On 19.08.20 19:33, Mike Rapoport wrote:
quoted
On Wed, Aug 19, 2020 at 02:10:43PM +0200, David Hildenbrand wrote:
quoted
On 19.08.20 13:53, Mike Rapoport wrote:
quoted
On Wed, Aug 19, 2020 at 12:49:05PM +0200, David Hildenbrand wrote:
quoted
On 18.08.20 16:15, Mike Rapoport wrote:
quoted
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.
Wouldn't something like CMA be the better fit? Just wondering. Then, the
memory can actually be reused for something else while not needed.
The memory allocated as secret is removed from the direct map and the
boot time reservation is intended to reduce direct map fragmentatioan
and to avoid splitting 1G pages there. So with CMA I'd still need to
allocate 1G chunks for this and once 1G page is dropped from the direct
map it still cannot be reused for anything else until it is freed.
I could use CMA to do the boot time reservation, but doing the
reservesion directly seemed simpler and more explicit to me.
Well, using CMA would give you the possibility to let the memory be used
for other purposes until you decide it's the right time to take it +
remove the direct mapping etc.
I still can't say I follow you here. If I reseve a CMA area as a pool
for secret memory 1G pages, it is still reserved and it still cannot be
used for other purposes, right?
So, AFAIK, if you create a CMA pool it can be used for any MOVABLE
allocations (similar to ZONE_MOVABLE) until you actually allocate CMA
memory from that region. Other allocations on that are will then be
migrated away (using alloc_contig_range()).
For example, if you have a 1~GiB CMA area, you could allocate 4~MB pages
from that CMA area on demand (removing the direct mapping, etc ..), and
free when no longer needed (instantiating the direct mapping). The free
memory in that area could used for MOVABLE allocations.
The boot time resrvation is intended to avoid splitting 1G pages in the
direct map. Without the boot time reservation, we maintain a pool of 2M
pages so the 1G pages are split and 2M pages remain unsplit.
If I scale your example to match the requirement to avoid splitting 1G
pages in the direct map, that would mean creating a CMA area of several
tens of gigabytes and then doing cma_alloc() of 1G each time we need to
refill the secretmem pool.
It is quite probable that we won't be able to get 1G from CMA after the
system worked for some time.
Why? It should only contain movable pages, and if that is not the case,
it's a bug we have to fix. It should behave just as ZONE_MOVABLE.
(although I agree that in corner cases, alloc_contig_pages() might
temporarily fail on some chunks - e.g., with long/short-term page
pinnings - in contrast to memory offlining, it won't retry forever)
The use-case I had in mind for the boot time reservation in secretmem is
a machine that runs VMs and there is a desire to have the VM memory
protected from the host. In a way this should be similar to booting a
host with mem=X where most of the machine memory never gets to be used
by the host kernel.
For such use case, boot time reservation controlled by the command
line parameter seems to me simpler than using CMA. I agree that there is
no way to use the reserved memory for other purpose, but then we won't
need to create physically contiguous chunk of several gigs every time a
VM is created.
quoted
With boot time reservation we won't need physcally contiguous 1G to
satisfy smaller allocation requests for secretmem because we don't need
to maintain 1G mappings in the secretmem pool.
You can allocate within your CMA area however you want - doesn't need to
be whole gigabytes in case there is no need for it.
The whole point of boot time reservation is to prevent splitting 1G
pages in the direct map. Allocating smaller chunks will still cause
fragmentation of the direct map.
Again, the big benefit of CMA is that the reserved memory can be reused
for other purpose while nobody is actually making use of it.
Right, but I think if a user explicitly asked to use X gigabytes for the
secretmem we can allow that.
quoted
That said, I believe the addition of the boot time reservation, either
direct or with CMA, can be added as an incrememntal patch after the
"core" functionality is merged.
I am not convinced that we want to let random processes to do
alloc_pages() in the range of tens of gigabytes. It's not just mlocked
memory. I prefer either using CMA or relying on the boot time
reservations. But let's see if there are other opinions and people just
don't care.
Having that said, I have no further comments.
--
Thanks,
David / dhildenb