[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <ZkPXcT_JuQeZCAv0@casper.infradead.org>
Date: Tue, 14 May 2024 22:28:17 +0100
From: Matthew Wilcox <willy@...radead.org>
To: Jonathan Corbet <corbet@....net>
Cc: Andrew Morton <akpm@...ux-foundation.org>, jeffxu@...omium.org,
keescook@...omium.org, jannh@...gle.com, sroettger@...gle.com,
gregkh@...uxfoundation.org, torvalds@...ux-foundation.org,
usama.anjum@...labora.com, Liam.Howlett@...cle.com,
surenb@...gle.com, merimus@...gle.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 v10 0/5] Introduce mseal
On Tue, May 14, 2024 at 02:59:57PM -0600, Jonathan Corbet wrote:
> Andrew Morton <akpm@...ux-foundation.org> writes:
>
> > On Mon, 15 Apr 2024 16:35:19 +0000 jeffxu@...omium.org wrote:
> >
> >> This patchset proposes a new mseal() syscall for the Linux kernel.
> >
> > I have not moved this into mm-stable for a 6.10 merge. Mainly because
> > of the total lack of Reviewed-by:s and Acked-by:s.
> >
> > The code appears to be stable enough for a merge.
> >
> > It's awkward that we're in conference this week, but I ask people to
> > give consideration to the desirability of moving mseal() into mainline
> > sometime over the next week, please.
>
> I hate to be obnoxious, but I *was* copied ... :)
>
> Not taking a position on merging, but I have to ask: are we convinced at
> this point that mseal() isn't a chrome-only system call? Did we ever
> see the glibc patches that were promised?
I think _this_ version of mseal() is OpenBSD's mimmutable() with a
basically unused extra 'flags' argument. As such, we have an existance
proof that it's useful beyond Chrome.
I think Liam still had concerns around the
walk-the-vmas-twice-to-error-out-early part of the implementation?
Although we can always fix the implementation later; changing the API
is hard.
Powered by blists - more mailing lists