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

[Deepak Gupta]

On Thu, Jun 19, 2025 at 02:56:59PM +0800, Jesse Huang wrote:
>Hi Deepak,
>
>Thanks for your quick review.
>
>Thanks for letting me know the `map_shadow_stack` syscall is ready, I will
>switch to using it.

yeah if you look at sysdeps/unix/sysv/linux/x86_64/makecontext.c
It uses `__allocate_shadow_stack` which in turn calls `map_shadow_stack` sys
call on x86. We should something similar.

>
>For the token mechanism idea, there is no problem using it for
>setjmp/longjmp,
>I will also switch to it in the next version. However, for ucontext, there
>are
>two possibilities while doing a ucontext switch
>
>  1. SSP of both contexts were belongs to a same shadow stack region
>     (created by same logical thread), and needs unwind
>  2. SSP of both contexts were belongs to a different shadow stack region,
>     (created by different logical thread), and needs stack switch
>
>In `unix/sysv/linux/x86_64/setcontext.S`, there is a piece of code for
>testing whether the SSP of two contexts belong two a same shadow stack,
>which
>leverage the shadow stack base stored in the thread control block
>
>#if SHSTK_ENABLED
>/* Check if shadow stack is enabled.  */
>testl $X86_FEATURE_1_SHSTK, %fs:FEATURE_1_OFFSET
>jz L(no_shstk)
>
>/* If the base of the target shadow stack is the same as the
>  base of the current shadow stack, we unwind the shadow
>  stack.  Otherwise it is a stack switch and we look for a
>  restore token.  */
>movq oSSP(%rdx), %rsi
>movq %rsi, %rdi
>
>/* Get the base of the target shadow stack.  */
>movq (oSSP + 8)(%rdx), %rcx
>cmpq %fs:SSP_BASE_OFFSET, %rcx
>je L(unwind_shadow_stack)
>
>I think we are not able to distinguish two cases without storing the shadow
>stack base, do you have any idea on this, or maybe you mean we don't even
>need
>to unwind at all?

There is a quite a bit of long history behind why x86 did it this way. If I
have to shorten it, shadow stack token management instructions on x86 are a
bit constrained which forced them to do this. Ask HJ Lu / Rick Edgecombe or
we can hop on a call and I can explain the history.

In case of RISC-V, this is not needed at all. As long as we can find a home
for ssp in ucontext and doing save of token on switching away and validating
token during switching time, we don't have to do this at all.