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