RE: [RFC PATCH] mm: extend memfd with ability to create "secret" memory areas

[Reshetova, Elena]

> 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.