linux-kernel - Re: [RFC PATCH] mm: extend memfd with ability to create "secret" memory areas

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20200208173922.GA15879@hump>
Date:   Sat, 8 Feb 2020 19:39:22 +0200
From:   Mike Rapoport <rppt@...nel.org>
To:     Dave Hansen <dave.hansen@...el.com>
Cc:     linux-kernel@...r.kernel.org, Alan Cox <alan@...ux.intel.com>,
        Andrew Morton <akpm@...ux-foundation.org>,
        Andy Lutomirski <luto@...nel.org>,
        Christopher Lameter <cl@...ux.com>,
        Dave Hansen <dave.hansen@...ux.intel.com>,
        James Bottomley <jejb@...ux.ibm.com>,
        "Kirill A. Shutemov" <kirill@...temov.name>,
        Matthew Wilcox <willy@...radead.org>,
        Peter Zijlstra <peterz@...radead.org>,
        "Reshetova, Elena" <elena.reshetova@...el.com>,
        Thomas Gleixner <tglx@...utronix.de>,
        Tycho Andersen <tycho@...ho.ws>, linux-api@...r.kernel.org,
        linux-mm@...ck.org
Subject: Re: [RFC PATCH] mm: extend memfd with ability to create "secret"
 memory areas

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

Another usecase is the VM memory.

-- 
Sincerely yours,
Mike.