Received-SPF: pass (google.com: domain of linux-kernel+bounces-43577-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:40f1:3f00::1 as permitted sender) client-ip=2604:1380:40f1:3f00::1;
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()
In-Reply-To: <20240122152905.2220849-1-jeffxu@chromium.org>
References: <20240122152905.2220849-1-jeffxu@chromium.org>
Date: Mon, 29 Jan 2024 15:36:58 -0700
Message-ID: <87a5ong41h.fsf@meer.lwn.net>
Precedence: bulk
MIME-Version: 1.0
Content-Type: text/plain

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