From: "Reshetova, Elena" <elena.reshetova@intel.com>
To: Mike Rapoport <rppt@kernel.org>, "Hansen, Dave" <dave.hansen@intel.com>
Cc: "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
Alan Cox <alan@linux.intel.com>,
Andrew Morton <akpm@linux-foundation.org>,
"Andy Lutomirski" <luto@kernel.org>,
Christopher Lameter <cl@linux.com>,
"Dave Hansen" <dave.hansen@linux.intel.com>,
James Bottomley <jejb@linux.ibm.com>,
"Kirill A. Shutemov" <kirill@shutemov.name>,
Matthew Wilcox <willy@infradead.org>,
Peter Zijlstra <peterz@infradead.org>,
Thomas Gleixner <tglx@linutronix.de>,
Tycho Andersen <tycho@tycho.ws>,
"linux-api@vger.kernel.org" <linux-api@vger.kernel.org>,
"linux-mm@kvack.org" <linux-mm@kvack.org>
Subject: RE: [RFC PATCH] mm: extend memfd with ability to create "secret" memory areas
Date: Mon, 10 Feb 2020 08:06:49 +0000 [thread overview]
Message-ID: <BL0PR11MB3281C858712D469C88F52537E7190@BL0PR11MB3281.namprd11.prod.outlook.com> (raw)
In-Reply-To: <20200208173922.GA15879@hump>
> 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.
next prev parent reply other threads:[~2020-02-10 8:06 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-01-30 16:23 [RFC PATCH] mm: extend memfd with ability to create "secret" memory areas Mike Rapoport
2020-02-06 18:51 ` Dave Hansen
2020-02-08 17:39 ` Mike Rapoport
2020-02-10 8:06 ` Reshetova, Elena [this message]
2020-02-11 19:52 ` Edgecombe, Rick P
2020-02-12 21:10 ` Jonathan Corbet
2020-02-16 6:46 ` Mike Rapoport
2020-08-14 17:46 ` Andy Lutomirski
2020-08-14 18:09 ` Dave Hansen
2020-08-26 16:54 ` Andy Lutomirski
2020-08-26 19:01 ` Florian Weimer
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=BL0PR11MB3281C858712D469C88F52537E7190@BL0PR11MB3281.namprd11.prod.outlook.com \
--to=elena.reshetova@intel.com \
--cc=akpm@linux-foundation.org \
--cc=alan@linux.intel.com \
--cc=cl@linux.com \
--cc=dave.hansen@intel.com \
--cc=dave.hansen@linux.intel.com \
--cc=jejb@linux.ibm.com \
--cc=kirill@shutemov.name \
--cc=linux-api@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=luto@kernel.org \
--cc=peterz@infradead.org \
--cc=rppt@kernel.org \
--cc=tglx@linutronix.de \
--cc=tycho@tycho.ws \
--cc=willy@infradead.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).