Jeff Xu jeffxu@google.com wrote:
Or when would you *ever* say "seal this area, but mprotect()" is ok.
The fact that openBSD allows RW=>RO transaction, as in its man page [2]
" At present, mprotect(2) may reduce permissions on immutable pages marked PROT_READ | PROT_WRITE to the less permissive PROT_READ."
Let me explain this.
We encountered two places that needed this less-permission-transition.
Both of these problems were found in either .data or bss, which the kernel makes immutable by default. The OpenBSD kernel makes those regions immutable BY DEFAULT, and there is no way to turn that off.
One was in our libc malloc, which after initialization, wants to protect a control data structure from being written in the future.
The other was in chrome v8, for the v8_flags variable, this is similarily mprotected to less permission after initialization to avoid tampering (because it's an amazing relative-address located control gadget).
We introduced a different mechanism to solve these problem.
So we added a new ELF section which annotates objects you need to be MUTABLE. If these are .data or .bss, they are placed in the MUTABLE region annotated with the following Program Header:
Program Headers: Type Offset VirtAddr PhysAddr FileSiz MemSiz Flg Align OPENBSD_MUTABLE 0x0e9000 0x00000000000ec000 0x00000000000ec000 0x001000 0x001000 RW 0x1000
associated with this Section Header
[20] .openbsd.mutable PROGBITS 00000000000ec000 0e9000 001000 00 WA 0 0 4096
(It is vaguely similar to RELRO).
You can place objects there using the a compiler __attribute__((section declaration, like this example from our libc/malloc.c code
static union { struct malloc_readonly mopts; u_char _pad[MALLOC_PAGESIZE]; } malloc_readonly __attribute__((aligned(MALLOC_PAGESIZE))) __attribute__((section(".openbsd.mutable")));
During startup the code can set the protection and then the immutability of the object correctly.
Since we have no purpose left for this permission reduction semantic upon immutable mappings, we may be deleting that behaviour in the future. I wrote that code, because I needed it to make progress with some difficult pieces of code. But we found a better way.