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

[Jesse Huang]

Thanks for the clarification, that sounds good.
Yes then I can change it to using the token mechanism, and surely
I would like to know about the rationale of x86 behind, I will send you
email for a call

On Thu, Jun 19, 2025 at 4:22 PM Deepak Gupta <debug@rivosinc.com> wrote:

> 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.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://sourceware.org/pipermail/libc-alpha/attachments/20250620/d8d6bbf4/attachment.htm>