Jeff Xu <jeffxu@xxxxxxxxxxxx> writes: > On Mon, Jan 29, 2024 at 2:37 PM Jonathan Corbet <corbet@xxxxxxx> wrote: >> >> jeffxu@xxxxxxxxxxxx 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
