Regarding these pieces
> The PROT_SEAL bit in prot field of mmap(). When present, it marks
> the map sealed since creation.
OpenBSD won't be doing this. I had PROT_IMMUTABLE as a draft. In my
research I found basically zero circumstances when you userland does
that. The most common circumstance is you create a RW mapping, fill it,
and then change to a more restrictve mapping, and lock it.
There are a few regions in the addressspace that can be locked while RW.
For instance, the stack. But the kernel does that, not userland. I
found regions where the kernel wants to do this to the address space,
but there is no need to export useless functionality to userland.
OpenBSD now uses this for a high percent of the address space. It might
be worth re-reading a description of the split of responsibility regarding
who locks different types of memory in a process;
- kernel (the majority, based upon what ELF layout tell us),
- shared library linker (the next majority, dealing with shared
library mappings and left-overs not determinable at kernel time),
- libc (a small minority, mostly regarding forced mutable objects)
- and the applications themselves (only 1 application today)
https://lwn.net/Articles/915662/
> The MAP_SEALABLE bit in the flags field of mmap(). When present, it marks
> the map as sealable. A map created without MAP_SEALABLE will not support
> sealing, i.e. mseal() will fail.
We definately won't be doing this. We allow a process to lock any and all
it's memory that isn't locked already, even if it means it is shooting
itself in the foot.
I think you are going to severely hurt the power of this mechanism,
because you won't be able to lock memory that has been allocated by a
different callsite not under your source-code control which lacks the
MAP_SEALABLE flag. (Which is extremely common with the system-parts of
a process, meaning not just libc but kernel allocated objects).
It may be fine inside a program like chrome, but I expect that flag to make
it harder to use in libc, and it will hinder adoption.
