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

[Jesse Huang]

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.

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