linux-kernel - Re: Sealed memfd & no-fault mmap

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: <CAHk-=wiAs7Ky9gmWAeqk5t7Nkueip13XPGtUcmMiZjwf-sX3sQ@mail.gmail.com>
Date:   Tue, 4 May 2021 09:08:33 -0700
From:   Linus Torvalds <torvalds@...ux-foundation.org>
To:     Simon Ser <contact@...rsion.fr>
Cc:     Peter Xu <peterx@...hat.com>,
        "Kirill A. Shutemov" <kirill@...temov.name>,
        Matthew Wilcox <willy@...radead.org>,
        Dan Williams <dan.j.williams@...el.com>,
        "Kirill A. Shutemov" <kirill.shutemov@...ux.intel.com>,
        Will Deacon <will@...nel.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        David Herrmann <dh.herrmann@...il.com>,
        "linux-mm@...ck.org" <linux-mm@...ck.org>,
        Greg Kroah-Hartman <greg@...ah.com>,
        "tytso@....edu" <tytso@....edu>
Subject: Re: Sealed memfd & no-fault mmap

On Tue, May 4, 2021 at 2:29 AM Simon Ser <contact@...rsion.fr> wrote:
>
> The remaining 10% is when the compositor needs a writable mapping for
> things like screen capture. It doesn't seem like a SIGBUS handler can
> be avoided in this case then… Oh well.

So as Peter Xu mentioned, if we made it a "per inode" thing, we
probably could make such an inode do the zero page fill on its own,
and it might be ok for certain cases even for shared mappings.

However, realistically I think it's a horrible idea for the generic
situation, because I think that basically requires the filesystem
itself to buy into it. And we have something like 60+ different
filesystems.

Is there some very specific and targeted pattern for that "shared
mapping" case? For example, if it's always a shared anonymous mapping
with no filesystem backing, then that would possibly be a simpler case
than the "random arbitrary shared file descriptor".

But maybe that simpler (if untested) VM patch is fine if 90% of the
time it's a plain normal non-shared mapping, and you have to have the
SIGBUS case for backwards compatibility anyway, but at least some
_benign_ cases are now handled without pain...

                    Linus