[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAHk-=wjqozic6JuRimXD=RamnJmD6FoaQki7RtNYrezzx_OfOg@mail.gmail.com>
Date: Thu, 1 Feb 2024 15:15:27 -0800
From: Linus Torvalds <torvalds@...ux-foundation.org>
To: Theo de Raadt <deraadt@...nbsd.org>
Cc: Jeff Xu <jeffxu@...omium.org>, "Liam R. Howlett" <Liam.Howlett@...cle.com>,
Jonathan Corbet <corbet@....net>, akpm@...ux-foundation.org, keescook@...omium.org,
jannh@...gle.com, sroettger@...gle.com, willy@...radead.org,
gregkh@...uxfoundation.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
Subject: Re: [PATCH v8 0/4] Introduce mseal
On Thu, 1 Feb 2024 at 14:54, Theo de Raadt <deraadt@...nbsd.org> wrote:
>
> Linus, you are in for a shock when the proposal doesn't work for glibc
> and all the applications!
Heh. I've enjoyed seeing your argumentative style that made you so
famous back in the days. Maybe it's always been there, but I haven't
seen the BSD people in so long that I'd forgotten all about it.
That said, famously argumentative or not, I think Theo is right, and I
do think the MAP_SEALABLE bit is nonsensical.
If somebody wants to mseal() a memory region, why would they need to
express that ahead of time?
So the part I think is sane is the mseal() system call itself, in that
it allows *potential* future expansion of the semantics.
But hopefully said future expansion isn't even needed, and all users
want the base experience, which is why I think PROT_SEAL (both to mmap
and to mprotect) makes sense as an alternative form.
So yes, to my mind
mprotect(addr, len, PROT_READ);
mseal(addr, len, 0);
should basically give identical results to
mprotect(addr, len, PROT_READ | PROT_SEAL);
and using PROT_SEAL at mmap() time is similarly the same obvious
notion of "map this, and then seal that mapping".
The reason for having "mseal()" as a separate call at all from the
PROT_SEAL bit is that it does allow possible future expansion (while
PROT_SEAL is just a single bit, and it won't change semantics) but
also so that you can do whatever prep-work in stages if you want to,
and then just go "now we seal it all".
Linus
Powered by blists - more mailing lists