linux-kernel - Re: [PATCH RFC 1/3] mm: Add f

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]

Date:   Mon, 7 Mar 2022 15:26:11 +0200
From:   Jarkko Sakkinen <jarkko@...nel.org>
To:     Matthew Wilcox <willy@...radead.org>
Cc:     Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        linux-mm@...ck.org, Dave Hansen <dave.hansen@...ux.intel.com>,
        Nathaniel McCallum <nathaniel@...fian.com>,
        Reinette Chatre <reinette.chatre@...el.com>,
        Andrew Morton <akpm@...ux-foundation.org>,
        linux-sgx@...r.kernel.org, linux-kernel@...r.kernel.org,
        Florian Fainelli <f.fainelli@...il.com>,
        Thomas Bogendoerfer <tsbogend@...ha.franken.de>,
        Matthew Auld <matthew.auld@...el.com>,
        Thomas Hellström 
        <thomas.hellstrom@...ux.intel.com>,
        Daniel Vetter <daniel.vetter@...ll.ch>,
        Jason Ekstrand <jason@...kstrand.net>,
        Chris Wilson <chris@...is-wilson.co.uk>,
        Maarten Lankhorst <maarten.lankhorst@...ux.intel.com>,
        Tvrtko Ursulin <tvrtko.ursulin@...el.com>,
        Shakeel Butt <shakeelb@...gle.com>,
        Vasily Averin <vvs@...tuozzo.com>,
        zhangyiru <zhangyiru3@...wei.com>,
        Alexander Mikhalitsyn <alexander.mikhalitsyn@...tuozzo.com>,
        Alexey Gladkov <legion@...nel.org>, linux-mips@...r.kernel.org,
        intel-gfx@...ts.freedesktop.org, dri-devel@...ts.freedesktop.org,
        codalist@...a.cs.cmu.edu, linux-unionfs@...r.kernel.org,
        linux-fsdevel@...r.kernel.org
Subject: Re: [PATCH RFC 1/3] mm: Add f_ops->populate()

On Mon, Mar 07, 2022 at 03:16:57PM +0200, Jarkko Sakkinen wrote:
> On Sun, Mar 06, 2022 at 10:43:31PM +0000, Matthew Wilcox wrote:
> > On Sun, Mar 06, 2022 at 07:02:57PM +0200, Jarkko Sakkinen wrote:
> > > So can I conclude from this that in general having populate available for
> > > device memory is something horrid, or just the implementation path?
> > 
> > You haven't even attempted to explain what the problem is you're trying
> > to solve.  You've shown up with some terrible code and said "Hey, is
> > this a good idea".  No, no, it's not.
> 
> The problem is that in order to include memory to enclave, which is
> essentially a reserved address range processes virtual address space
> there's two steps into it:
> 
> 1. Host side (kernel) does ENCLS[EAUG] to request a new page to be
>    added to the enclave.
> 2. Enclave accepts request with ENCLU[EACCEPT] or ENCLU[EACCEPTCOPY].
> 
> In the current SGX2 patch set this taken care by the page fault
> handler. I.e. the enclave calls ENCLU[EACCEPT] for an empty address
> and the #PF handler then does EAUG for a single page.
> 
> So if you want to process a batch of pages this generates O(n)
> round-trips.
> 
> So if there was a way pre-do a batch of EAUG's, that would allow
> to load data to the enclave without causing page faults happening
> constantly.
> 
> One solution for this simply add ioctl:
> 
> https://lore.kernel.org/linux-sgx/YiLRBglTEbu8cHP9@iki.fi/T/#m195ec84bf85614a140abeee245c5118c22ace8f3
> 
> But in practice when you wanted to use it, you would setup the
> parameters so that they match the mmap() range. So for pratical
> user space API having mmap() take care of this would be much more
> lean option.

For something like Graphene [1] the lazy #PF based option is probably
a way to go. For wasm runtime that we're doing in Enarx [2] we get better
performance by having something like this. I.e. we most of the time take
as much as we use.

[1] https://github.com/gramineproject/graphene
[2] https://enarx.dev/

BR, Jarkko