[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CABi2SkV4Q9CY+vb+t_+7RN_EtFB+FUi4ObHaZWo_+KMt7u4yDA@mail.gmail.com>
Date: Wed, 31 Jan 2024 09:49:15 -0800
From: Jeff Xu <jeffxu@...omium.org>
To: Jonathan Corbet <corbet@....net>
Cc: 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, 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
Subject: Re: [PATCH v7 0/4] Introduce mseal()
On Mon, Jan 29, 2024 at 2:37 PM Jonathan Corbet <corbet@....net> wrote:
>
> 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.
>
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!
Thanks
-Jeff
> Thanks,
>
> jon
Powered by blists - more mailing lists