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

[Florian Weimer]

* > On Mon, Jun 16, 2025 at 1:10 PM Florian Weimer <fweimer@redhat.com> wrote:
>>
>> > On Sat, Jun 14, 2025 at 1:22 AM Florian Weimer <fweimer@redhat.com> wrote:
>> >>
>> >> > 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...)
>> >>
>> >> The challenge is that all the code up to this point needs to be compiled
>> >> differently.  We have rtld-early-cflags for that (which unfortunatelly
>> >> cannot be set automatically).  But as I said, I'm not sure if using it
>> >> conflicts with the purpose of the shadow stack extension (to protect
>> >> return instructions).
>> >
>> > it's unfortunate, but i don't think it's any different from the
>> > existing arm64 x18 software stack protector stuff in that way. (or
>> > stack-protector, or any of the other things that libc just can't use
>> > until libc has done the necessary setup...)
>>
>> Yeah, I think dropping the marker instructions should fail in the right
>> direction: the functions simply aren't callable through pointers once we
>> enable indirect branch hardening.  I don't know to what extend the
>> return hardening instructions imply landing pads for indirect branch
>> hardening.  But even if there's an implication, it should still fail
>> safely.  But again, I have not fully worked out the details.
>
> the landing pad stuff is a separate extension:
> https://github.com/riscv/riscv-cfi/blob/main/src/cfi_forward.adoc
>
> so it's possible to have either lp or ss, neither, or both. but the
> worst part [that debug@ was trying to address] is that it's also
> possible to have chips with neither that _also_ don't just ignore
> these instructions; they fault. unlike arm64, where armv8.0 had the
> "hint" instructions that correspond to risc-v's "maybe ops". ("hint"
> means something else to risc-v.)

I'm aware of that problem. That's why there's the occasional desire to
burn everything down and start over from scratch, which is what adopting
RVA23 (or anything with zimop/zcmop) would be today.  And that's when
we'd need the startup diagnostics, based on our past experience.

(At the technical level, we went exactly this thing with the ppc64le
bringup: the original hardware was POWER7-based and did not support the
vector ISA.  This wasn't a problem for a while even once POWER8 had
launched because GCC did not generate many vector instructions yet.  Of
course that changed over the time, and this led to a lot confusion
because we did not have rtld-early-cflags and the ld.so compatibility
diagnostic at the time.  Where the analogy breaks down is that POWER7 LE
hardware was never widely available.)

Thanks,
Florian