Messages in this thread | | | Subject | Re: [RFC PATCH] mm: extend memfd with ability to create "secret" memory areas | From | Dave Hansen <> | Date | Thu, 6 Feb 2020 10:51:13 -0800 |
| |
On 1/30/20 8:23 AM, Mike Rapoport wrote: > include/linux/memfd.h | 9 ++ > include/uapi/linux/magic.h | 1 + > include/uapi/linux/memfd.h | 6 + > mm/Kconfig | 4 + > mm/Makefile | 1 + > mm/memfd.c | 10 +- > mm/secretmem.c | 244 +++++++++++++++++++++++++++++++++++++ > 7 files changed, 273 insertions(+), 2 deletions(-)
It seems pretty self-contained and relatively harmless.
But, how much work is it going to be to tell the rest of the kernel that page_to_virt() doesn't work any more? Do we need to make kmap() work on these?
I guess fixing vm_normal_page() would fix a lot of that.
In general, my concern about creating little self-contained memory types is that they will get popular and folks will start wanting more features from them. For instance, what if I want NUMA affinity, migration, or large page mappings that are secret?
Can these pages work as guest memory?
Who would the first users of this thing be?
| |