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

[Florian Weimer]

> 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.

Thanks,
Florian