On Mon, Jun 1, 2026 at 10:10 AM Andreas Schwab <[email protected]> wrote: > > On Jun 01 2026, Deepak Gupta wrote: > > > This was settled when x86 introduced shadow stack. Instead of having > > new `PROT_`, it was agreed to create a new syscall for mapping shadow > > stack memory (syscall: `map_shadow_stack`). Scenarios like `clone3` or > > co-routines required manufacturing a shadow stack, thus necessitating a > > new mechanism to create shadow stack style memory in demand. Instead > > of having a new PROT_ flag, a new syscall was created. > > So what prevents riscv from making use of VM_SHADOW_STACK similar as > x86, without the user visible effects?
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. see commit message """ Earlier `protection_map[VM_WRITE]` used to pick read-write PTE encodings. Now `protection_map[VM_WRITE]` will always pick PAGE_SHADOWSTACK PTE encodings for shadow stack. Above changes ensure that existing apps continue to work because underneath kernel will be picking `protection_map[VM_WRITE|VM_READ]` PTE encodings. """ As I said other arches have a VMA flag for shadow stack range but PTE encodings and overlays are complicated. > > -- > Andreas Schwab, [email protected] > GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510 2552 DF73 E780 A9DA AEC1 > "And now for something completely different."
