Received-SPF: pass (google.com: domain of linux-kernel+bounces-47101-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:45d1:ec00::1 as permitted sender) client-ip=2604:1380:45d1:ec00::1;
From: Jonathan Corbet <corbet@lwn.net>
To: Jeff Xu <jeffxu@chromium.org>
Cc: akpm@linux-foundation.org, keescook@chromium.org, jannh@google.com,
 sroettger@google.com, willy@infradead.org, gregkh@linuxfoundation.org,
 torvalds@linux-foundation.org, usama.anjum@collabora.com,
 rdunlap@infradead.org, jeffxu@google.com, jorgelo@chromium.org,
 groeck@chromium.org, linux-kernel@vger.kernel.org,
 linux-kselftest@vger.kernel.org, linux-mm@kvack.org,
 pedro.falcato@gmail.com, dave.hansen@intel.com,
 linux-hardening@vger.kernel.org, deraadt@openbsd.org
Subject: Re: [PATCH v7 0/4] Introduce mseal()
In-Reply-To: <CABi2SkV4Q9CY+vb+t_+7RN_EtFB+FUi4ObHaZWo_+KMt7u4yDA@mail.gmail.com>
References: <20240122152905.2220849-1-jeffxu@chromium.org>
 <87a5ong41h.fsf@meer.lwn.net>
 <CABi2SkV4Q9CY+vb+t_+7RN_EtFB+FUi4ObHaZWo_+KMt7u4yDA@mail.gmail.com>
Date: Wed, 31 Jan 2024 13:51:42 -0700
Message-ID: <87le854469.fsf@meer.lwn.net>
Precedence: bulk
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

Jeff Xu <jeffxu@chromium.org> writes:

> On Mon, Jan 29, 2024 at 2:37=E2=80=AFPM Jonathan Corbet <corbet@lwn.net> =
wrote:
>>
>> jeffxu@chromium.org writes:
>>
>> > Although the initial version of this patch series is targeting the
>> > Chrome browser as its first user, it became evident during upstream
>> > discussions that we would also want to ensure that the patch set
>> > eventually is a complete solution for memory sealing and compatible
>> > with other use cases. The specific scenario currently in mind is
>> > glibc's use case of loading and sealing ELF executables. To this end,
>> > Stephen is working on a change to glibc to add sealing support to the
>> > dynamic linker, which will seal all non-writable segments at startup.
>> > Once this work is completed, all applications will be able to
>> > automatically benefit from these new protections.
>>
>> Is this work posted somewhere?  Having a second - and more generally
>> useful - user for this API would do a lot to show that the design is, in
>> fact, right and useful beyond the Chrome browser.
>>
> Stephen conducted a PoC last year, it will be published once it is comple=
te.
> We're super excited about introducing this as a general safety measure
> for all of Linux!

We're excited too, something like mseal() seems like a good thing to
have.  My point, though, is that it would be good to see this second
(and more general) user of the API *before* merging it.  As others have
noted, once mseal() is in a released kernel, it will be difficult to
change if adjustments turn out to be necessary.

Thanks,

jon