[PATCH v23 24/28] arch/riscv: dual vdso creation logic and select vdso based on hw

[Charles Mirabile]

On Thu, Dec 4, 2025 at 12:04 PM Thomas Weißschuh
<thomas.weissschuh at linutronix.de> wrote:
>
> On Wed, Nov 12, 2025 at 04:43:22PM -0800, Deepak Gupta via B4 Relay wrote:
> > From: Deepak Gupta <debug at rivosinc.com>
> >
> > Shadow stack instructions are taken from zimop (mandated on RVA23).
> > Any hardware prior to RVA23 profile will fault on shadow stack instruction.
> > Any userspace with shadow stack instruction in it will fault on such
> > hardware. Thus such userspace can't be brought onto such a hardware.
> >
> > It's not known how userspace will respond to such binary fragmentation.
> > However in order to keep kernel portable across such different hardware,
> > `arch/riscv/kernel/vdso_cfi` is created which has logic (Makefile) to
> > compile `arch/riscv/kernel/vdso` sources with cfi flags and then changes
> > in `arch/riscv/kernel/vdso.c` for selecting appropriate vdso depending
> > on whether underlying hardware(cpu) implements zimop extension. Offset
> > of vdso symbols will change due to having two different vdso binaries,
> > there is added logic to include new generated vdso offset header and
> > dynamically select offset (like for rt_sigreturn).
>
> If the used vDSO variant only depends on the hardware and nothing else,
> why not use alternative patching and avoid the complexity?
> I see that RISCV_ALTERNATIVE depends on !XIP_KERNEL but the vDSO code is
> moved to dynamically allocated memory in any case, so it is patchable.

These instructions are emitted by the toolchain in the C code, so a
traditional approach with alternatives is not exactly feasible. Maybe
you could do it by scan the binary for them, but that sounds dubious.

>
> > Signed-off-by: Deepak Gupta <debug at rivosinc.com>
> > Acked-by: Charles Mirabile <cmirabil at redhat.com>
>
> (...)
>