> On Thu, Feb 06, 2020 at 10:51:13AM -0800, Dave Hansen wrote: > > 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? > > Why page_to_virt() won't work anymore? Or you refer to that the kernel code > won't be able to access the page contents? > > > Do we need to make kmap() work on these? > > I don't think we need to make kmap() work on these. The idea is to prevent > kernel from accessing such memory areas. > > > 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? > > Sure, why not :) > Well, this is true for any feature: it may become popular, people will > start using it and it will add more complexity. > > My goal is to design this thing keeping in mind that all the above (and > probably more) will be requested sooner or later. > > > Can these pages work as guest memory? > > Actually, this is one of the driving usecases. I believe that people that > use mem=X to limit kernel control of the memory and the manage the > remaining memory for the guests can switch to fd-based approach. > > > Who would the first users of this thing be? > > We were thinking about using such areas to store small secrets, e.g. with > openssl_malloc(). > To elaborate more on this - openssl has "secure heap" feature [1], which is basically a mmap area with MLOCK_ONFAULT and MADV_DONTDUMP. It is optional feature and can be used for storing things like RSA private keys in a bit more secure memory area (vs. just normal allocation). It is fully transparent for userspace applications (hidden behind openssl API), but provides additional security when enabled. So, it seems like a natural candidate for smth like securememory, which in addition to MLOCK_ONFAULT and MADV_DONTDUMP can provide further security guarantees like exclusive memory and no-caching. [1] https://www.openssl.org/docs/manmaster/man3/OPENSSL_secure_malloc.html Best Regards, Elena.
