Andreas Schwab <[email protected]> writes: > On Jun 01 2026, Deepak Gupta wrote: > >> riscv uses `VM_SHADOW_STACK`. It's just very simple to use `protection_map` >> with just `VM_WRITE`. On RISC-V, `-W-` is a shadow stack mapping. It's not >> same >> on x86 or arm64. So `protection_map[VM_WRITE]` simply picks shadow stack >> encoding. We just ensure that PROT_WRITE is converted to >> "VM_READ | VM_WRITE" at vma level. > > That does not explain _why_ you need to make that user visible change, > when others can get away without it.
Especially since as I recall the decision was made was that the user visible protection bits would match the mmap call. If there is some combination an architecture does not support that would simply not be reflected in hardware until some future version of the hardware gets around to supporting it. This is what happened with executable page permissions on x86 for example. It used to be that it was not possible to deny execute permission on a readable page. Later that proved sufficiently valuable that support for denying execute permission was added to the hardware. That all happened quite transparently to userspace, that wasn't trying to assuming PROT_READ implied PROT_EXEC. So I am at a complete loss why someone would choose to break userspace by confusing hardware limitations with what userspace asks for in mmap. Eric
