[PATCH RFC v2] RISCV: insert zimop instruction at the start

[enh]

On Fri, Jun 13, 2025 at 3:53 PM Florian Weimer <fweimer@redhat.com> wrote:
>
> > On Fri, Jun 13, 2025 at 12:42 AM Deepak Gupta <debug@rivosinc.com> wrote:
> >>
> >> RVA23 mandates that CPU must implement zimop and zcmop extensions. These
> >> extensions are termed as "may be operations" to signify that some instructions
> >> might be leveraged by some future extensions to turn into different operations.
> >> Unless those extensions are used for codegen, there is no way to ensure that
> >> compiled software has zimop/zcmop instruction in them. Without any software
> >> using these instructions, there is no way to ensure that target hardware is
> >> RVA23 compatible.
> >>
> >> zicfiss extension converts some of the zimop instructions into shadow stack
> >> instructions. Support for shadow stack is still in the flux. This patch ensures
> >> that if compiler supports shadow stack codegen then sspush/sspopchk
> >> instructions are at the start when userspace starts life. Kernel doesn't enable
> >> shadow stack for userspace by default. Userspace will issue shadow stack enable
> >> prtctls to kernel. Thus always these (sspush/sspopchk) instructions will
> >> default to zimop behavior.
> >>
> >> Note that this is not a backward hardware compatible change.
> >>
> >> Signed-off-by: Deepak Gupta <debug@rivosinc.com>
> >> ---
> >> RVA23 mandates that CPU must implement zimop and zcmop extensions. These
> >> extensions are termed as "may be operations" to signify that some instructions
> >> might be leveraged by some future extensions to turn into different operations.
> >> Unless those extensions are used for codegen, there is no way to ensure that
> >> compiled software has zimop/zcmop instruction in them. Without any software
> >> using these instructions, there is no way to ensure that target hardware is
> >> RVA23 compatible.
> >>
> >> zicfiss extension converts some of the zimop instructions into shadow stack
> >> instructions. Support for shadow stack is still in the flux. This patch ensures
> >> that if compiler supports shadow stack codegen then sspush/sspopchk
> >> instructions are at the start when userspace starts life. Kernel doesn't enable
> >> shadow stack for userspace by default. Userspace will issue shadow stack enable
> >> prctls to kernel. Thus always these (sspush/sspopchk) instructions will
> >> default to zimop behavior.
> >>
> >> Note that this is not a backward hardware compatible change.
> >> ---
> >> Changes in v2:
> >> - changing sspop to c.sspopchk. sspopchk is the instruction. making it
> >>   c.sspopchk to check for zcmop.
> >>
> >> - Link to v1: https://inbox.sourceware.org/20250612-glibc_zimop-v1-1-88f15a37d233@rivosinc.com
> >> ---
> >>  sysdeps/riscv/dl-machine.h | 10 ++++++++++
> >>  1 file changed, 10 insertions(+)
> >>
> >> diff --git a/sysdeps/riscv/dl-machine.h b/sysdeps/riscv/dl-machine.h
> >> index dcc3e0883b..9870320cf0 100644
> >> --- a/sysdeps/riscv/dl-machine.h
> >> +++ b/sysdeps/riscv/dl-machine.h
> >> @@ -53,6 +53,15 @@
> >>       || (__WORDSIZE == 64 && (type) == R_RISCV_TLS_TPREL64)))  \
> >>     | (ELF_RTYPE_CLASS_COPY * ((type) == R_RISCV_COPY)))
> >>
> >> +
> >> +#ifdef __riscv_zicfiss
> >
> > doesn't the #ifdef make this useless? you'll only emit these
> > instructions if you've enabled ss in your build (and thus presumably
> > emitting them for real), so you're not really testing the "maybe" side
> > of things at all?
>
> Yes, the #ifdef should be for the “this won't always trap” extension.
>
> > don't you actually want to have a couple of unconditional `.inst`s for
> > any build claiming zimop/zicmop instead?
>
> Right.
>
> > and even if you do that, is this a good place to do it? crashes here
> > tend to be hard to interpret/debug, especially without a SIGILL signal
> > handler to say "hey, you're running a build that requires zimop on a
> > non-zimop device".
>
> Well, I expect this to happen mostly with builds for the RVA23 profile,
> and those will have plenty other reasons for crashes.
>
> We might be able to get a nice diagnostic using <gccmacros.h> and logic
> in <dl-hwcap-check.h>, as on POWER and Z.  But I don't know if this is
> possible without compromising security hardening overall (the early
> ld.so code needs to be built for the baseline ISA and will therefore
> have unprotected return instructions).
>
> > does __riscv_hwprobe() for zimop make more sense?
>
> The shadow stack changes end up basicaly everywhere, so it's not
> suitable for run-time dispatch.

oh, i didn't mean anything that fancy --- i just meant "before you set
it up for the main thread, check with __riscv_hwprobe() whether the
kernel thinks the hardware you're running on actually supports zimop
and if not tell them that while this code _ought_ to be able to run on
both ss and non-ss capable systems, it won't run on yours because you
don't have zimop". (though whether __riscv_hwprobe() or a SIGILL type
check makes more sense probably depends on what problems we see in
real life...)

> Thanks,
> Florian
>