On Thu, 1 Feb 2024 at 14:54, Theo de Raadt deraadt@openbsd.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