Re: [PATCH v23 06/28] riscv/mm : ensure PROT_WRITE leads to VM_READ | VM_WRITE

["Eric W. Biederman" <ebiederm@xmission.com>]

Andreas Schwab <schwab@linux-m68k.org> 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