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:   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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ