On Thu, Dec 4, 2025 at 12:04 PM Thomas Weißschuh thomas.weissschuh@linutronix.de wrote:
On Wed, Nov 12, 2025 at 04:43:22PM -0800, Deepak Gupta via B4 Relay wrote:
From: Deepak Gupta debug@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@rivosinc.com Acked-by: Charles Mirabile cmirabil@redhat.com
(...)