On Tue, Jun 2, 2026 at 3:23 AM Eric W. Biederman <[email protected]> wrote: > > 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.
Initially my plan was to re-use (only) VM_WRITE as (alias to) VM_SHADOW_STACK on risc-v to match hardware Write-only PTE encoding and I didn't see any opposition to that initially. Until later when it was suggested to use distinct VM_SHADOW_STACK encoding. Although there wasn't any oppostion to this patch, seems like it made it in. Now that I take a look at it, I think it can be made to work. Sorry about that. Now that I have switched my affiliation to meta, I'll have to spend some time to set up risc-v dev environment. I'll send a patch. Thanks. > > Eric >
