On Thu, Dec 4, 2025 at 12:04 PM Thomas Weißschuh <[email protected]> wrote: > > On Wed, Nov 12, 2025 at 04:43:22PM -0800, Deepak Gupta via B4 Relay wrote: > > From: Deepak Gupta <[email protected]> > > > > 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 <[email protected]> > > Acked-by: Charles Mirabile <[email protected]> > > (...) >
