[PATCH v2 00/14] Support RISC-V Control Flow Integrifty (CFI)

[Vivian Wang]

On 7/23/25 17:12, Jesse Huang wrote:
> Hi Henrich,
>
> Thanks for your question.
> For dynamic binaries, the loader performs a check on all dependencies
> listed in link_map, and CFI features (SS, LP) will only be enabled
> respectively only if property notes present in all of the dependencies.
> I have summarized the possible combinations and their behavior here.
>
> 1) Binary w/o CFI
> No compatibility problem
>
> 2) Binary w/ CFI + dependency w/ CFI
> CFI will be enabled and should be no problem
>
> 3) Binary w/ CFI + dynamic loading library w/o CFI
> a. If the mode is always-on (default), dlopen will fail.
> b. If the mode is permissive (can be set by glibc tunables),
>    CFI will be disabled
>
> 4) Binary w/ CFI + dependency w/o CFI
> CFI will not be enabled because of the dependency check won't pass
>
> The only case that causes problem is attempting to execute shadow stack
> instructions on a RVA20 machine, in this case they will be illegal
> instructions due to lacking the support of Zimop/Zcmop, but this is
> unlikely to happen.

The problems is that, AFAICT, now the size of jmp_buf depends on
__riscv_shadow_stack. You have mentioned this in passing in the cover
letter, but this is a huge problem for the software ecosystem because
there will always be binary code that depends on the size of jmp_buf by
e.g. using it in a struct.

We did that to s390 [1] back in 2014 once. It was bad. Let's not do that
again.

Can we learn from what x86 and aarch64 did that did not cause this
problem? My understanding is that they used some otherwise unused
storage in the full jmp_buf, but I'm not sure about the details.

Thanks,
Vivian "dramforever" Wang

[1]: https://lwn.net/Articles/606377/