Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
MIME-Version: 1.0
References: <vs1Us2sm4qmfvLOqNat0-r16GyfmWzqUzQ4KHbXJwEcjhzeoQ4sBTxx7QXDG9B6zk5AeT7FsNb3CSr94LaKy6Novh1fbbw8D_BBxYsbPLms=@emersion.fr>
In-Reply-To: <vs1Us2sm4qmfvLOqNat0-r16GyfmWzqUzQ4KHbXJwEcjhzeoQ4sBTxx7QXDG9B6zk5AeT7FsNb3CSr94LaKy6Novh1fbbw8D_BBxYsbPLms=@emersion.fr>
From:   Linus Torvalds <torvalds@linux-foundation.org>
Date:   Tue, 27 Apr 2021 09:51:58 -0700
Message-ID: <CAHk-=wgmGv2EGscKSi8SrQWtEVpEQyk-ZN1Xj4EoAB87Dmx1gA@mail.gmail.com>
Subject: Re: Sealed memfd & no-fault mmap
To:     Simon Ser <contact@emersion.fr>,
        "Kirill A. Shutemov" <kirill.shutemov@linux.intel.com>,
        Peter Xu <peterx@redhat.com>, Will Deacon <will@kernel.org>
Cc:     Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
        David Herrmann <dh.herrmann@gmail.com>,
        "linux-mm@kvack.org" <linux-mm@kvack.org>,
        Greg Kroah-Hartman <greg@kroah.com>,
        "tytso@mit.edu" <tytso@mit.edu>
Content-Type: multipart/mixed; boundary="0000000000008cfa7505c0f7158a"
Precedence: bulk

--0000000000008cfa7505c0f7158a
Content-Type: text/plain; charset="UTF-8"

On Tue, Apr 27, 2021 at 1:25 AM Simon Ser <contact@emersion.fr> wrote:
>
> Rather than requiring changes in all compositors *and* clients, can we
> maybe only require changes in compositors? For instance, OpenBSD has a
> __MAP_NOFAULT flag. When passed to mmap, it means that out-of-bound
> accesses will read as zeroes instead of triggering SIGBUS. Such a flag
> would be very helpful to unblock the annoying SIGBUS situation.
>
> Would something among these lines be welcome in the Linux kernel?

Hmm. It doesn't look too hard to do. The biggest problem is actually
that we've run out of flags in the vma (on 32-bit architectures), but
you could try this UNTESTED patch that just does the MAP_NOFAULT thing
unconditionally.

NOTE! Not only is it untested, not only is this a "for your testing
only" (because it does it unconditionally rather than only for
__MAP_NOFAULT), but it might be bogus for other reasons. In
particular, this patch depends on "vmf->address" not being changed by
the ->fault() infrastructure, so that we can just re-use the vmf for
the anonymous case if we get a SIGBUS.

I think that's all ok these days, because Kirill and Peter Xu cleaned
up those paths, but I didn't actually check. So I'm cc'ing Kirill,
Peter and Will, who have been working in this area for other reasons
fairly recently.

Side note: this will only ever work for non-shared mappings. That's
fundamental. We won't add an anonymous page to a shared mapping, and
do_anonymous_page() does verify that. So a MAP_SHARED mappign will
still return SIGBUS even with this patch (although it's not obvious
from the patch - the VM_FAULT_SIGBUS will just be re-created by
do_anonymous_page()).

So if you want a _shared_ mapping to honor __MAP_NOFAULT and insert
random anonymous pages into it, I think the answer is "no, that's not
going to be viable".

So _if_ this works for you, and if it's ok that only MAP_PRIVATE can
have __MAP_NOFAULT, and if Kirill/Peter/Will don't say "Oh, Linus,
you're completely off your rocker and clearly need to be taking your
meds", something like this - if we figure out the conditional bit -
might be doable.

That's a fair number of "ifs".

Ok, back to the merge window for me, I'll be throwing away this crazy
untested patch immediately after hitting "send". This is very much a
"throw the idea over to other people" patch, in other words.

            Linus

--0000000000008cfa7505c0f7158a
Content-Type: text/x-patch; charset="US-ASCII"; name="patch.diff"
Content-Disposition: attachment; filename="patch.diff"
Content-Transfer-Encoding: base64
Content-ID: <f_ko09ogpl0>
X-Attachment-Id: f_ko09ogpl0

IG1tL21lbW9yeS5jIHwgMTkgKysrKysrKysrKysrKysrLS0tLQogMSBmaWxlIGNoYW5nZWQsIDE1
IGluc2VydGlvbnMoKyksIDQgZGVsZXRpb25zKC0pCgpkaWZmIC0tZ2l0IGEvbW0vbWVtb3J5LmMg
Yi9tbS9tZW1vcnkuYwppbmRleCA1NTA0MDVmYzNiNWUuLmJiZWRlNmI1MmY3YSAxMDA2NDQKLS0t
IGEvbW0vbWVtb3J5LmMKKysrIGIvbW0vbWVtb3J5LmMKQEAgLTQzMTIsMTAgKzQzMTIsMjEgQEAg
c3RhdGljIHZtX2ZhdWx0X3QgaGFuZGxlX3B0ZV9mYXVsdChzdHJ1Y3Qgdm1fZmF1bHQgKnZtZikK
IAl9CiAKIAlpZiAoIXZtZi0+cHRlKSB7Ci0JCWlmICh2bWFfaXNfYW5vbnltb3VzKHZtZi0+dm1h
KSkKLQkJCXJldHVybiBkb19hbm9ueW1vdXNfcGFnZSh2bWYpOwotCQllbHNlCi0JCQlyZXR1cm4g
ZG9fZmF1bHQodm1mKTsKKwkJaWYgKCF2bWFfaXNfYW5vbnltb3VzKHZtZi0+dm1hKSkgeworCQkJ
dm1fZmF1bHRfdCByZXQgPSBkb19mYXVsdCh2bWYpOworCQkJaWYgKHJldCAmIFZNX0ZBVUxUX1JF
VFJZKQorCQkJCXJldHVybiByZXQ7CisJCQlpZiAoIShyZXQgJiBWTV9GQVVMVF9TSUdCVVMpKQor
CQkJCXJldHVybiByZXQ7CisvKiBGSVhNRSEgV2UgZG9uJ3QgaGF2ZSBhIFZNX05PRkFVTFQgYml0
ICovCisjaWYgMAorCQkJLyogU2VlIGlmIHdlIHNob3VsZCB0dXJuIGEgU0lHQlVTIGludG8gYW4g
YW5vbnltb3VzIHBhZ2UgKi8KKwkJCWlmICghKHZtYS0+dm1fZmxhZ3MgJiBWTV9OT0ZBVUxUKSkK
KwkJCQlyZXR1cm4gcmV0OworI2VuZGlmCisvKiBGYWxsIGJhY2sgb24gZG9fYW5vbnltb3VzX3Bh
Z2UoKSBpbnN0ZWFkIG9mIFNJR0JVUyAqLworCQl9CisJCXJldHVybiBkb19hbm9ueW1vdXNfcGFn
ZSh2bWYpOwogCX0KIAogCWlmICghcHRlX3ByZXNlbnQodm1mLT5vcmlnX3B0ZSkpCg==
--0000000000008cfa7505c0f7158a--