Some notes about compatibility between mimmutable(2) and mseal().
This morning, the "RW -> R demotion" code in mimmutable(2) was removed. As described previously, that was a development crutch to solved a problem but we found a better way with a new ELF section which is available at compile time with __attribute__((section(".openbsd.mutable"))). Which works great.
I am syncronizing the madvise / msync behaviour further, we will be compatible. I have worried about madvise / msync for a long time, and audited vast amounts of the software ecosystem to come to a conclusion we can be more strict, but I never acted upon it.
BTW, on OpenBSD and probably other related BSD operating systems, MADV_DONTNEED is non-destructive. However we have a destructive operation called MADV_FREE. msync() MS_INVALIDATE is also destructive. But all of these operations will now be prohibited, to syncronize the error return value situation.
There is an one large difference remainig between mimmutable() and mseal(), which is how other system calls behave.
We return EPERM for failures in all the system calls that fail upon immutable memory (since Oct 2022).
You are returning EACESS.
Before it is too late, do you want to reconsider that return value, or do you have a justification for the choice?
I think this remains the blocker which would prevent software from doing
#define mimmutable(addr, len) mseal(addr, len, 0)