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

From: Jonathan Corbet <corbet@lwn.net>
To: jeffxu@chromium.org, akpm@linux-foundation.org,
	keescook@chromium.org, jannh@google.com, sroettger@google.com,
	willy@infradead.org, gregkh@linuxfoundation.org,
	torvalds@linux-foundation.org, usama.anjum@collabora.com,
	rdunlap@infradead.org
Cc: jeffxu@google.com, jorgelo@chromium.org, groeck@chromium.org,
	linux-kernel@vger.kernel.org, linux-kselftest@vger.kernel.org,
	linux-mm@kvack.org, pedro.falcato@gmail.com,
	dave.hansen@intel.com, linux-hardening@vger.kernel.org,
	deraadt@openbsd.org, Jeff Xu <jeffxu@chromium.org>
Subject: Re: [PATCH v7 0/4] Introduce mseal()
Date: Mon, 29 Jan 2024 15:36:58 -0700	[thread overview]
Message-ID: <87a5ong41h.fsf@meer.lwn.net> (raw)
In-Reply-To: <20240122152905.2220849-1-jeffxu@chromium.org>

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.

Thanks,

jon