Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
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
Thread-Topic: [RFC PATCH] mm: extend memfd with ability to create "secret"
 memory areas
Thread-Index: AQHV14m+Mmd68cx3eUajc6Oqc5ecjqgOjbuAgAMQlgCAAoLcYA==
Date:   Mon, 10 Feb 2020 08:06:49 +0000
Message-ID: <BL0PR11MB3281C858712D469C88F52537E7190@BL0PR11MB3281.namprd11.prod.outlook.com>
References: <20200130162340.GA14232@rapoport-lnx>
 <df5a888b-1a11-e806-741d-94684b22c966@intel.com>
 <20200208173922.GA15879@hump>
In-Reply-To: <20200208173922.GA15879@hump>
Accept-Language: en-US
Content-Language: en-US
dlp-version: 11.2.0.6
dlp-product: dlpe-windows
dlp-reaction: no-action
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: a3457665-bbf5-4e02-57df-08d7ae002e41
X-MS-Exchange-CrossTenant-originalarrivaltime: 10 Feb 2020 08:06:49.4232
 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 46c98d88-e344-4ed4-8496-4ed7712e255d
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: x/J3zDVxQn9KBYz6VlZAvHSBRh48BOZukAUlqHPY1+4SKInZ2Vt27r8aeIsW2YX8IGhTxnwpk3bwqCR2Wsy5asZkcLzH9z5m7yuRyXrU/tQ=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BL0PR11MB3300
X-OriginatorOrg: intel.com
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org


> 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 tha=
t
> > page_to_virt() doesn't work any more?
>=20
> Why page_to_virt() won't work anymore? Or you refer to that the kernel co=
de
> won't be able to access the page contents?
>=20
> > Do we need to make kmap() work on these?
>=20
> I don't think we need to make kmap() work on these. The idea is to preven=
t
> kernel from accessing such memory areas.
>=20
> > I guess fixing vm_normal_page() would fix a lot of that.
> >
> > In general, my concern about creating little self-contained memory type=
s
> > is that they will get popular and folks will start wanting more feature=
s
> > from them.  For instance, what if I want NUMA affinity, migration, or
> > large page mappings that are secret?
>=20
> 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.
>=20
> My goal is to design this thing keeping in mind that all the above (and
> probably more) will be requested sooner or later.
>=20
> > Can these pages work as guest memory?
>=20
> Actually, this is one of the driving usecases. I believe that people that
> use mem=3DX to limit kernel control of the memory and the manage the
> remaining memory for the guests can switch to fd-based approach.
>=20
> > Who would the first users of this thing be?
>=20
> We were thinking about using such areas to store small secrets, e.g. with
> openssl_malloc().
>=20

To elaborate more on this - openssl has "secure heap" feature [1], which=20
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=
=20
transparent for userspace applications (hidden behind openssl API), but=20
provides additional security when enabled. So, it seems like a natural cand=
idate
for smth like securememory, which in addition to MLOCK_ONFAULT and=20
MADV_DONTDUMP can provide further security guarantees like exclusive=20
memory and no-caching.=20

[1] https://www.openssl.org/docs/manmaster/man3/OPENSSL_secure_malloc.html

Best Regards,
Elena.