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

[Deepak Gupta]

On Mon, Jun 16, 2025 at 01:29:23PM -0400, enh wrote:
>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.)

So I tried to do conditional compile of under definition of `__riscv_zimop`.
But this gets defined if compiler was aware of `__riscv_zimop` and even if
-march string is not provided.

>
>> Thanks,
>> Florian
>>