Re: [PATCH v7 0/4] Introduce mseal()

[Jonathan Corbet <corbet@lwn.net>]

Jeff Xu <jeffxu@chromium.org> writes:

> On Mon, Jan 29, 2024 at 2:37 PM 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 complete.
> 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