Received-SPF: pass (google.com: domain of linux-kernel+bounces-188791-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:45e3:2400::1 as permitted sender) client-ip=2604:1380:45e3:2400::1;
Feedback-ID: id2994666:Fastmail
User-Agent: Cyrus-JMAP/3.11.0-alpha0-480-g515a2f54a-fm-20240515.001-g515a2f54
Precedence: bulk
MIME-Version: 1.0
Message-Id: <f880562e-9521-4270-82e2-c6fb14dc853a@app.fastmail.com>
In-Reply-To: 
 <CALmYWFtedtEnfGFp5DYacHYOE7+GB8yoQC-iyw7JAxySmgQ7vw@mail.gmail.com>
References: <20240513191544.94754-1-pobrn@protonmail.com>
 <CALmYWFt7MYbWrCDVEKH4DrMQGxaXA2kK8qth-JVxzkvMd6Ohtg@mail.gmail.com>
 <20240522162324.0aeba086228eddd8aff4f628@linux-foundation.org>
 <1KDsEBw8g7ymBVpGJZp9NRH1HmCBsQ_jjQ_jKOg90gLUFhW5W6lcG-bI4-5OPkrD24RiG7G83VoZL4SXPQjfldsNFDg7bFnFFgrVZWwSWXQ=@protonmail.com>
 <08450f80-4c33-40db-886f-fee18e531545@app.fastmail.com>
 <CALmYWFv9dK5ZPzwx3WCLMXzuuDadvFxh84+8rrT7aL105+ZZAQ@mail.gmail.com>
 <CALmYWFtedtEnfGFp5DYacHYOE7+GB8yoQC-iyw7JAxySmgQ7vw@mail.gmail.com>
Date: Fri, 24 May 2024 16:28:50 +0200
From: "David Rheinsberg" <david@readahead.eu>
To: "Jeff Xu" <jeffxu@google.com>, "Aleksa Sarai" <cyphar@cyphar.com>
Cc: =?UTF-8?Q?Barnab=C3=A1s_P=C5=91cze?= <pobrn@protonmail.com>,
 "Andrew Morton" <akpm@linux-foundation.org>, linux-mm@kvack.org,
 linux-kernel@vger.kernel.org, linux-kselftest@vger.kernel.org,
 dmitry.torokhov@gmail.com, "Daniel Verkamp" <dverkamp@chromium.org>,
 hughd@google.com, jorgelo@chromium.org, skhan@linuxfoundation.org,
 "Kees Cook" <keescook@chromium.org>
Subject: Re: [PATCH v1] memfd: `MFD_NOEXEC_SEAL` should not imply `MFD_ALLOW_SEALING`
Content-Type: text/plain;charset=utf-8
Content-Transfer-Encoding: quoted-printable

Hi

On Thu, May 23, 2024, at 6:55 PM, Jeff Xu wrote:
> On Thu, May 23, 2024 at 9:20=E2=80=AFAM Jeff Xu <jeffxu@google.com> wr=
ote:
>> On Thu, May 23, 2024 at 1:24=E2=80=AFAM David Rheinsberg <david@reada=
head.eu> wrote:
>> > We asked for exactly this fix before, so I very much support this. =
Our test-suite in `dbus-broker` merely verifies what the current kernel =
behavior is (just like the kernel selftests). I am certainly ok if the k=
ernel breaks it. I will gladly adapt the test-suite.
>> >
> memfd is by default not sealable, and file is by default sealable,
> right ? that makes the memfd  semantics different from other objects
> in linux.
> I wonder what is the original reason to have memfd  this way?

shmem-files are *not* sealable by default. This design was followed for =
backward compatibility reasons, since shmem-files predate sealing and si=
lently enabling sealing on all shmem-files would have broken existing us=
ers (see shmem.c which initializes seals to F_SEAL_SEAL).

I am not sure what you mean with "makes [memfd] semantics different from=
 other objects in linux". Can you elaborate?

Since `memfd_create` was introduced at the same time as shmem-sealing, i=
t could certainly have enabled sealing by default. Not sure whether this=
 would be preferable, though.

> Another solution is to change memfd to be by-default sealable,
> although that will be an api change, but what side effect  will it be
> ?
> If we are worried about the memfd being sealed by an attacker, the
> malicious code could also overwrite the content since memfd is not
> sealed.

You cannot change the default-seals retrospectively. There are existing =
shmem-users that share file-descriptors and *expect* the other party to =
be able to override data, but do *not* expect the other party to be able=
 to apply seals. Note that these models explicitly *want* shared, writab=
le access to the buffer (e.g., render-client shares a buffer with the di=
splay server for scanout), so just because you can *write* to a shmem-fi=
le does not mean that sharing is unsafe (e.g., using SIGBUS+mmap can saf=
ely deal with page-faults).

Thanks
David