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.