Linus Torvalds torvalds@linux-foundation.org wrote:
and using PROT_SEAL at mmap() time is similarly the same obvious notion of "map this, and then seal that mapping".
The usual way is:
ptr = mmap(NULL, len PROT_READ|PROT_WRITE, ...)
initialize region between ptr, ptr+len
mprotect(ptr, len, PROT_READ) mseal(ptr, len, 0);
Our source tree contains one place where a locking happens very close to a mmap().
It is the shared-library-linker 'hints file', this is a file that gets mapped PROT_READ and then we lock it.
It feels like that could be one operation? It can't be.
addr = (void *)mmap(0, hsize, PROT_READ, MAP_PRIVATE, hfd, 0); if (_dl_mmap_error(addr)) goto bad_hints;
hheader = (struct hints_header *)addr; if (HH_BADMAG(*hheader) || hheader->hh_ehints > hsize) goto bad_hints;
/* couple more error checks */
mimmutable(addr, hsize); close(hfd); return (0); bad_hints: munmap(addr, hsize); ...
See the problem? It unmaps it if the contents are broken. So even that case cannot use something like "PROT_SEAL".
These are not hypotheticals. I'm grepping an entire Unix kernel and userland source tree, and I know what 100,000+ applications do. I found piece of code that could almost use it, but upon inspection it can't, and it is obvious why: it is best idiom to allow a programmer to insert an inspection operation between two disctinct operations, and especially critical if the 2nd operation cannot be reversed.
Noone needs PROT_SEAL as a shortcut operation in mmap() or mprotect().
Throwing around ideas without proving their use in practice is very unscientific.