[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <87a5ong41h.fsf@meer.lwn.net>
Date: Mon, 29 Jan 2024 15:36:58 -0700
From: Jonathan Corbet <corbet@....net>
To: jeffxu@...omium.org, akpm@...ux-foundation.org, keescook@...omium.org,
jannh@...gle.com, sroettger@...gle.com, willy@...radead.org,
gregkh@...uxfoundation.org, torvalds@...ux-foundation.org,
usama.anjum@...labora.com, rdunlap@...radead.org
Cc: jeffxu@...gle.com, jorgelo@...omium.org, groeck@...omium.org,
linux-kernel@...r.kernel.org, linux-kselftest@...r.kernel.org,
linux-mm@...ck.org, pedro.falcato@...il.com, dave.hansen@...el.com,
linux-hardening@...r.kernel.org, deraadt@...nbsd.org, Jeff Xu
<jeffxu@...omium.org>
Subject: Re: [PATCH v7 0/4] Introduce mseal()
jeffxu@...omium.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.
Thanks,
jon
Powered by blists - more mailing lists