Message ID | 20250314-v5_user_cfi_series-v12-5-e51202b53138@rivosinc.com |
---|---|
State | New |
Headers | show |
Series | riscv control-flow integrity for usermode | expand |
On 14/03/2025 22:39, Deepak Gupta wrote: > Carves out space in arch specific thread struct for cfi status and shadow > stack in usermode on riscv. > > This patch does following > - defines a new structure cfi_status with status bit for cfi feature > - defines shadow stack pointer, base and size in cfi_status structure > - defines offsets to new member fields in thread in asm-offsets.c > - Saves and restore shadow stack pointer on trap entry (U --> S) and exit > (S --> U) > > Shadow stack save/restore is gated on feature availiblity and implemented > using alternative. CSR can be context switched in `switch_to` as well but > soon as kernel shadow stack support gets rolled in, shadow stack pointer > will need to be switched at trap entry/exit point (much like `sp`). It can > be argued that kernel using shadow stack deployment scenario may not be as > prevalant as user mode using this feature. But even if there is some > minimal deployment of kernel shadow stack, that means that it needs to be > supported. And thus save/restore of shadow stack pointer in entry.S instead > of in `switch_to.h`. > > Reviewed-by: Charlie Jenkins <charlie@rivosinc.com> > Reviewed-by: Zong Li <zong.li@sifive.com> > Signed-off-by: Deepak Gupta <debug@rivosinc.com> > --- > arch/riscv/include/asm/processor.h | 1 + > arch/riscv/include/asm/thread_info.h | 3 +++ > arch/riscv/include/asm/usercfi.h | 24 ++++++++++++++++++++++++ > arch/riscv/kernel/asm-offsets.c | 4 ++++ > arch/riscv/kernel/entry.S | 26 ++++++++++++++++++++++++++ > 5 files changed, 58 insertions(+) > > diff --git a/arch/riscv/include/asm/processor.h b/arch/riscv/include/asm/processor.h > index e3aba3336e63..d851bb5c6da0 100644 > --- a/arch/riscv/include/asm/processor.h > +++ b/arch/riscv/include/asm/processor.h > @@ -14,6 +14,7 @@ > > #include <asm/ptrace.h> > #include <asm/hwcap.h> > +#include <asm/usercfi.h> > > #define arch_get_mmap_end(addr, len, flags) \ > ({ \ > diff --git a/arch/riscv/include/asm/thread_info.h b/arch/riscv/include/asm/thread_info.h > index f5916a70879a..a0cfe00c2ca6 100644 > --- a/arch/riscv/include/asm/thread_info.h > +++ b/arch/riscv/include/asm/thread_info.h > @@ -62,6 +62,9 @@ struct thread_info { > long user_sp; /* User stack pointer */ > int cpu; > unsigned long syscall_work; /* SYSCALL_WORK_ flags */ > +#ifdef CONFIG_RISCV_USER_CFI > + struct cfi_status user_cfi_state; > +#endif > #ifdef CONFIG_SHADOW_CALL_STACK > void *scs_base; > void *scs_sp; > diff --git a/arch/riscv/include/asm/usercfi.h b/arch/riscv/include/asm/usercfi.h > new file mode 100644 > index 000000000000..5f2027c51917 > --- /dev/null > +++ b/arch/riscv/include/asm/usercfi.h > @@ -0,0 +1,24 @@ > +/* SPDX-License-Identifier: GPL-2.0 > + * Copyright (C) 2024 Rivos, Inc. > + * Deepak Gupta <debug@rivosinc.com> > + */ > +#ifndef _ASM_RISCV_USERCFI_H > +#define _ASM_RISCV_USERCFI_H > + > +#ifndef __ASSEMBLY__ > +#include <linux/types.h> > + > +#ifdef CONFIG_RISCV_USER_CFI > +struct cfi_status { > + unsigned long ubcfi_en : 1; /* Enable for backward cfi. */ > + unsigned long rsvd : ((sizeof(unsigned long) * 8) - 1); > + unsigned long user_shdw_stk; /* Current user shadow stack pointer */ > + unsigned long shdw_stk_base; /* Base address of shadow stack */ > + unsigned long shdw_stk_size; /* size of shadow stack */ > +}; > + > +#endif /* CONFIG_RISCV_USER_CFI */ > + > +#endif /* __ASSEMBLY__ */ > + > +#endif /* _ASM_RISCV_USERCFI_H */ > diff --git a/arch/riscv/kernel/asm-offsets.c b/arch/riscv/kernel/asm-offsets.c > index e89455a6a0e5..0c188aaf3925 100644 > --- a/arch/riscv/kernel/asm-offsets.c > +++ b/arch/riscv/kernel/asm-offsets.c > @@ -50,6 +50,10 @@ void asm_offsets(void) > #endif > > OFFSET(TASK_TI_CPU_NUM, task_struct, thread_info.cpu); > +#ifdef CONFIG_RISCV_USER_CFI > + OFFSET(TASK_TI_CFI_STATUS, task_struct, thread_info.user_cfi_state); > + OFFSET(TASK_TI_USER_SSP, task_struct, thread_info.user_cfi_state.user_shdw_stk); > +#endif > OFFSET(TASK_THREAD_F0, task_struct, thread.fstate.f[0]); > OFFSET(TASK_THREAD_F1, task_struct, thread.fstate.f[1]); > OFFSET(TASK_THREAD_F2, task_struct, thread.fstate.f[2]); > diff --git a/arch/riscv/kernel/entry.S b/arch/riscv/kernel/entry.S > index 33a5a9f2a0d4..68c99124ea55 100644 > --- a/arch/riscv/kernel/entry.S > +++ b/arch/riscv/kernel/entry.S > @@ -147,6 +147,20 @@ SYM_CODE_START(handle_exception) > > REG_L s0, TASK_TI_USER_SP(tp) > csrrc s1, CSR_STATUS, t0 > + /* > + * If previous mode was U, capture shadow stack pointer and save it away > + * Zero CSR_SSP at the same time for sanitization. > + */ > + ALTERNATIVE("nop; nop; nop; nop", You could use __nops(4) here instead. > + __stringify( \ > + andi s2, s1, SR_SPP; \ > + bnez s2, skip_ssp_save; \ > + csrrw s2, CSR_SSP, x0; \ > + REG_S s2, TASK_TI_USER_SSP(tp); \ > + skip_ssp_save:), > + 0, > + RISCV_ISA_EXT_ZICFISS, > + CONFIG_RISCV_USER_CFI) > csrr s2, CSR_EPC > csrr s3, CSR_TVAL > csrr s4, CSR_CAUSE > @@ -236,6 +250,18 @@ SYM_CODE_START_NOALIGN(ret_from_exception) > * structures again. > */ > csrw CSR_SCRATCH, tp > + > + /* > + * Going back to U mode, restore shadow stack pointer > + */ > + ALTERNATIVE("nop; nop", Ditto > + __stringify( \ > + REG_L s3, TASK_TI_USER_SSP(tp); \ > + csrw CSR_SSP, s3), > + 0, > + RISCV_ISA_EXT_ZICFISS, > + CONFIG_RISCV_USER_CFI) > + > 1: > #ifdef CONFIG_RISCV_ISA_V_PREEMPTIVE > move a0, sp > Apart from the nits above, you can add: Reviewed-by: Alexandre Ghiti <alexghiti@rivosinc.com> Thanks, Alex
2025-03-14T14:39:24-07:00, Deepak Gupta <debug@rivosinc.com>: > diff --git a/arch/riscv/include/asm/thread_info.h b/arch/riscv/include/asm/thread_info.h > @@ -62,6 +62,9 @@ struct thread_info { > long user_sp; /* User stack pointer */ > int cpu; > unsigned long syscall_work; /* SYSCALL_WORK_ flags */ > +#ifdef CONFIG_RISCV_USER_CFI > + struct cfi_status user_cfi_state; > +#endif I don't think it makes sense to put all the data in thread_info. kernel_ssp and user_ssp is more than enough and the rest can comfortably live elsewhere in task_struct. thread_info is supposed to be as small as possible -- just spanning multiple cache-lines could be noticeable. > diff --git a/arch/riscv/kernel/entry.S b/arch/riscv/kernel/entry.S > @@ -147,6 +147,20 @@ SYM_CODE_START(handle_exception) > > REG_L s0, TASK_TI_USER_SP(tp) > csrrc s1, CSR_STATUS, t0 > + /* > + * If previous mode was U, capture shadow stack pointer and save it away > + * Zero CSR_SSP at the same time for sanitization. > + */ > + ALTERNATIVE("nop; nop; nop; nop", > + __stringify( \ > + andi s2, s1, SR_SPP; \ > + bnez s2, skip_ssp_save; \ > + csrrw s2, CSR_SSP, x0; \ > + REG_S s2, TASK_TI_USER_SSP(tp); \ > + skip_ssp_save:), > + 0, > + RISCV_ISA_EXT_ZICFISS, > + CONFIG_RISCV_USER_CFI) (I'd prefer this closer to the user_sp and kernel_sp swap, it's breaking the flow here. We also already know if we've returned from userspace or not even without SR_SPP, but reusing the information might tangle the logic.) > csrr s2, CSR_EPC > csrr s3, CSR_TVAL > csrr s4, CSR_CAUSE > @@ -236,6 +250,18 @@ SYM_CODE_START_NOALIGN(ret_from_exception) > csrw CSR_SCRATCH, tp > + > + /* > + * Going back to U mode, restore shadow stack pointer > + */ Are we? I think we can be just as well returning back to kernel-space. Similar to how we can enter the exception handler from kernel-space. > + ALTERNATIVE("nop; nop", > + __stringify( \ > + REG_L s3, TASK_TI_USER_SSP(tp); \ > + csrw CSR_SSP, s3), > + 0, > + RISCV_ISA_EXT_ZICFISS, > + CONFIG_RISCV_USER_CFI) > + Thanks.
On Thu, Apr 24, 2025 at 01:52:43PM +0200, Radim Krčmář wrote: >2025-04-23T17:00:29-07:00, Deepak Gupta <debug@rivosinc.com>: >> On Thu, Apr 10, 2025 at 01:04:39PM +0200, Radim Krčmář wrote: >>>2025-03-14T14:39:24-07:00, Deepak Gupta <debug@rivosinc.com>: >>>> diff --git a/arch/riscv/include/asm/thread_info.h b/arch/riscv/include/asm/thread_info.h >>>> @@ -62,6 +62,9 @@ struct thread_info { >>>> long user_sp; /* User stack pointer */ >>>> int cpu; >>>> unsigned long syscall_work; /* SYSCALL_WORK_ flags */ >>>> +#ifdef CONFIG_RISCV_USER_CFI >>>> + struct cfi_status user_cfi_state; >>>> +#endif >>> >>>I don't think it makes sense to put all the data in thread_info. >>>kernel_ssp and user_ssp is more than enough and the rest can comfortably >>>live elsewhere in task_struct. >>> >>>thread_info is supposed to be as small as possible -- just spanning >>>multiple cache-lines could be noticeable. >> >> I can change it to only include only `user_ssp`, base and size. > >No need for base and size either -- we don't touch that in the common >exception code. got it. > >> But before we go there, see below: >> >> $ pahole -C thread_info kbuild/vmlinux >> struct thread_info { >> long unsigned int flags; /* 0 8 */ >> int preempt_count; /* 8 4 */ >> >> /* XXX 4 bytes hole, try to pack */ >> >> long int kernel_sp; /* 16 8 */ >> long int user_sp; /* 24 8 */ >> int cpu; /* 32 4 */ >> >> /* XXX 4 bytes hole, try to pack */ >> >> long unsigned int syscall_work; /* 40 8 */ >> struct cfi_status user_cfi_state; /* 48 32 */ >> /* --- cacheline 1 boundary (64 bytes) was 16 bytes ago --- */ >> long unsigned int a0; /* 80 8 */ >> long unsigned int a1; /* 88 8 */ >> long unsigned int a2; /* 96 8 */ >> >> /* size: 104, cachelines: 2, members: 10 */ >> /* sum members: 96, holes: 2, sum holes: 8 */ >> /* last cacheline: 40 bytes */ >> }; >> >> If we were to remove entire `cfi_status`, it would still be 72 bytes (88 bytes >> if shadow call stack were enabled) and already spans across two cachelines. > >It has only 64 bytes of data without shadow call stack, but it wasted 8 >bytes on the holes. >a2 is somewhat an outlier that is not used most exception paths and >excluding it makes everything fit nicely even now. But we can't exclude shadow call stack. It'll lead to increased size if that config is selected. A solution has to work for all the cases and not half hearted effort. > >> if shadow call stack were enabled) and already spans across two cachelines. I >> did see the comment above that it should fit inside a cacheline. Although I >> assumed its stale comment given that it already spans across cacheline and I >> didn't see any special mention in commit messages of changes which grew this >> structure above one cacheline. So I assumed this was a stale comment. >> >> On the other hand, whenever enable/lock bits are checked, there is a high >> likelyhood that user_ssp and other fields are going to be accessed and >> thus it actually might be helpful to have it all in one cacheline during >> runtime. > >Yes, although accessing enable/lock bits will be relatively rare. >It seems better to have the overhead during thread setup, rather than on >every trap. > >> So I am not sure if its helpful sticking to the comment which already is stale. > >We could fix the holes and also use sp instead of a0 in the >new_vmalloc_check, so everything would fit better. > >We are really close to fitting into a single cache-line, so I'd prefer >if shadow stack only filled thread_info with data that is used very >often in the exception handling code. I don't get what's the big deal if it results in two cachelines. We can (re)organize data structure in a way the most frequently accessed members are together in a single cacheline. We just need to find those members. In the hot path of exception handling, I see accesses to pt_regs on stack as well. These are definitley different cacheline than thread_info. I understand the argument of one member field crossing into two cachelines can have undesired perf effects. I do not understand reasoning that thread_info exactly has to fit inside one cacheline. If this was always supposed to fit in a single cacheline, clearly this invariant isn't/wasn't maintained as changes trickled in. I would like to see what maintainers have to say or someone who did data analysis on this. > >I think we could do without user_sp in thread_info as well, so there are >other packing options. Sure, probably somewhere in task_struct. But fact of the matter is that it has to be saved/restore during exception entry/exit. But then load/store to task_struct is essentially a different cachline. Not sure what we will achieve here? > >Btw. could ssp be added to pt_regs? I had that earlier. It breaks user abi. And it was a no go. > >Thanks.
On Thu, Apr 24, 2025 at 02:16:32PM +0200, Radim Krčmář wrote: >2025-04-23T17:23:56-07:00, Deepak Gupta <debug@rivosinc.com>: >> On Thu, Apr 10, 2025 at 01:04:39PM +0200, Radim Krčmář wrote: >>>2025-03-14T14:39:24-07:00, Deepak Gupta <debug@rivosinc.com>: >>>> diff --git a/arch/riscv/kernel/entry.S b/arch/riscv/kernel/entry.S >>>> @@ -147,6 +147,20 @@ SYM_CODE_START(handle_exception) >>>> >>>> REG_L s0, TASK_TI_USER_SP(tp) >>>> csrrc s1, CSR_STATUS, t0 >>>> + /* >>>> + * If previous mode was U, capture shadow stack pointer and save it away >>>> + * Zero CSR_SSP at the same time for sanitization. >>>> + */ >>>> + ALTERNATIVE("nop; nop; nop; nop", >>>> + __stringify( \ >>>> + andi s2, s1, SR_SPP; \ >>>> + bnez s2, skip_ssp_save; \ >>>> + csrrw s2, CSR_SSP, x0; \ >>>> + REG_S s2, TASK_TI_USER_SSP(tp); \ >>>> + skip_ssp_save:), >>>> + 0, >>>> + RISCV_ISA_EXT_ZICFISS, >>>> + CONFIG_RISCV_USER_CFI) >>> >>>(I'd prefer this closer to the user_sp and kernel_sp swap, it's breaking >>> the flow here. We also already know if we've returned from userspace >>> or not even without SR_SPP, but reusing the information might tangle >>> the logic.) >> >> If CSR_SCRATCH was 0, then we would be coming from kernel else flow goes >> to `.Lsave_context`. If we were coming from kernel mode, then eventually >> flow merges to `.Lsave_context`. >> >> So we will be saving CSR_SSP on all kernel -- > kernel trap handling. That >> would be unnecessary. IIRC, this was one of the first review comments in >> early RFC series of these patch series (to not touch CSR_SSP un-necessarily) >> >> We can avoid that by ensuring when we branch by determining if we are coming >> from user to something like `.Lsave_ssp` which eventually merges into >> ".Lsave_context". And if we were coming from kernel then we would branch to >> `.Lsave_context` and thus skipping ssp save logic. But # of branches it >> introduces in early exception handling is equivalent to what current patches >> do. So I don't see any value in doing that. >> >> Let me know if I am missing something. > >Right, it's hard to avoid the extra branches. > >I think we could modify the entry point (STVEC), so we start at >different paths based on kernel/userspace trap and only jump once to the >common code, like: > > SYM_CODE_START(handle_exception_kernel) > /* kernel setup magic */ > j handle_exception_common > SYM_CODE_START(handle_exception_user) > /* userspace setup magic */ > handle_exception_common: Hmm... This can be done. But then it would require to constantly modify `stvec` When you're going back to user mode, you would have to write `stvec` with addr of `handle_exception_user`. But then you can easily get a NMI. It can become ugly. Needs much more thought and on first glance feels error prone. Only if we have an extension that allows different trap address depending on mode you're coming from (arm does that, right?, I think x86 FRED also does that) > >This is not a suggestion for this series. I would be perfectly happy >with just a cleaner code. > >Would it be possible to hide the ALTERNATIVE ugliness behind a macro and >move it outside the code block that saves pt_regs? Sure, I'll do something about it. > >Thanks.
2025-04-24T11:03:59-07:00, Deepak Gupta <debug@rivosinc.com>: > On Thu, Apr 24, 2025 at 02:16:32PM +0200, Radim Krčmář wrote: >>2025-04-23T17:23:56-07:00, Deepak Gupta <debug@rivosinc.com>: >>> On Thu, Apr 10, 2025 at 01:04:39PM +0200, Radim Krčmář wrote: >>>>2025-03-14T14:39:24-07:00, Deepak Gupta <debug@rivosinc.com>: >>>>> diff --git a/arch/riscv/kernel/entry.S b/arch/riscv/kernel/entry.S >>>>> @@ -147,6 +147,20 @@ SYM_CODE_START(handle_exception) >>>>> >>>>> REG_L s0, TASK_TI_USER_SP(tp) >>>>> csrrc s1, CSR_STATUS, t0 >>>>> + /* >>>>> + * If previous mode was U, capture shadow stack pointer and save it away >>>>> + * Zero CSR_SSP at the same time for sanitization. >>>>> + */ >>>>> + ALTERNATIVE("nop; nop; nop; nop", >>>>> + __stringify( \ >>>>> + andi s2, s1, SR_SPP; \ >>>>> + bnez s2, skip_ssp_save; \ >>>>> + csrrw s2, CSR_SSP, x0; \ >>>>> + REG_S s2, TASK_TI_USER_SSP(tp); \ >>>>> + skip_ssp_save:), >>>>> + 0, >>>>> + RISCV_ISA_EXT_ZICFISS, >>>>> + CONFIG_RISCV_USER_CFI) >>>> >>>>(I'd prefer this closer to the user_sp and kernel_sp swap, it's breaking >>>> the flow here. We also already know if we've returned from userspace >>>> or not even without SR_SPP, but reusing the information might tangle >>>> the logic.) >>> >>> If CSR_SCRATCH was 0, then we would be coming from kernel else flow goes >>> to `.Lsave_context`. If we were coming from kernel mode, then eventually >>> flow merges to `.Lsave_context`. >>> >>> So we will be saving CSR_SSP on all kernel -- > kernel trap handling. That >>> would be unnecessary. IIRC, this was one of the first review comments in >>> early RFC series of these patch series (to not touch CSR_SSP un-necessarily) >>> >>> We can avoid that by ensuring when we branch by determining if we are coming >>> from user to something like `.Lsave_ssp` which eventually merges into >>> ".Lsave_context". And if we were coming from kernel then we would branch to >>> `.Lsave_context` and thus skipping ssp save logic. But # of branches it >>> introduces in early exception handling is equivalent to what current patches >>> do. So I don't see any value in doing that. >>> >>> Let me know if I am missing something. >> >>Right, it's hard to avoid the extra branches. >> >>I think we could modify the entry point (STVEC), so we start at >>different paths based on kernel/userspace trap and only jump once to the >>common code, like: >> >> SYM_CODE_START(handle_exception_kernel) >> /* kernel setup magic */ >> j handle_exception_common >> SYM_CODE_START(handle_exception_user) >> /* userspace setup magic */ >> handle_exception_common: > > Hmm... This can be done. But then it would require to constantly modify `stvec` > When you're going back to user mode, you would have to write `stvec` with addr > of `handle_exception_user`. We'd just be writing STVEC instead of SSCRATCH, probably at the very same places. It's possible that some micro-architectures will be disturbed more by writing STVEC than SSCRATCH, though, so it's not an easy change to make. > But then you can easily get a NMI. It can become > ugly. Needs much more thought and on first glance feels error prone. Yeah, the M-mode Linux adds a lot of fun. I don't see support for the Smrnmi extension, so unlucky NMIs should be fatal even now.
diff --git a/arch/riscv/include/asm/processor.h b/arch/riscv/include/asm/processor.h index e3aba3336e63..d851bb5c6da0 100644 --- a/arch/riscv/include/asm/processor.h +++ b/arch/riscv/include/asm/processor.h @@ -14,6 +14,7 @@ #include <asm/ptrace.h> #include <asm/hwcap.h> +#include <asm/usercfi.h> #define arch_get_mmap_end(addr, len, flags) \ ({ \ diff --git a/arch/riscv/include/asm/thread_info.h b/arch/riscv/include/asm/thread_info.h index f5916a70879a..a0cfe00c2ca6 100644 --- a/arch/riscv/include/asm/thread_info.h +++ b/arch/riscv/include/asm/thread_info.h @@ -62,6 +62,9 @@ struct thread_info { long user_sp; /* User stack pointer */ int cpu; unsigned long syscall_work; /* SYSCALL_WORK_ flags */ +#ifdef CONFIG_RISCV_USER_CFI + struct cfi_status user_cfi_state; +#endif #ifdef CONFIG_SHADOW_CALL_STACK void *scs_base; void *scs_sp; diff --git a/arch/riscv/include/asm/usercfi.h b/arch/riscv/include/asm/usercfi.h new file mode 100644 index 000000000000..5f2027c51917 --- /dev/null +++ b/arch/riscv/include/asm/usercfi.h @@ -0,0 +1,24 @@ +/* SPDX-License-Identifier: GPL-2.0 + * Copyright (C) 2024 Rivos, Inc. + * Deepak Gupta <debug@rivosinc.com> + */ +#ifndef _ASM_RISCV_USERCFI_H +#define _ASM_RISCV_USERCFI_H + +#ifndef __ASSEMBLY__ +#include <linux/types.h> + +#ifdef CONFIG_RISCV_USER_CFI +struct cfi_status { + unsigned long ubcfi_en : 1; /* Enable for backward cfi. */ + unsigned long rsvd : ((sizeof(unsigned long) * 8) - 1); + unsigned long user_shdw_stk; /* Current user shadow stack pointer */ + unsigned long shdw_stk_base; /* Base address of shadow stack */ + unsigned long shdw_stk_size; /* size of shadow stack */ +}; + +#endif /* CONFIG_RISCV_USER_CFI */ + +#endif /* __ASSEMBLY__ */ + +#endif /* _ASM_RISCV_USERCFI_H */ diff --git a/arch/riscv/kernel/asm-offsets.c b/arch/riscv/kernel/asm-offsets.c index e89455a6a0e5..0c188aaf3925 100644 --- a/arch/riscv/kernel/asm-offsets.c +++ b/arch/riscv/kernel/asm-offsets.c @@ -50,6 +50,10 @@ void asm_offsets(void) #endif OFFSET(TASK_TI_CPU_NUM, task_struct, thread_info.cpu); +#ifdef CONFIG_RISCV_USER_CFI + OFFSET(TASK_TI_CFI_STATUS, task_struct, thread_info.user_cfi_state); + OFFSET(TASK_TI_USER_SSP, task_struct, thread_info.user_cfi_state.user_shdw_stk); +#endif OFFSET(TASK_THREAD_F0, task_struct, thread.fstate.f[0]); OFFSET(TASK_THREAD_F1, task_struct, thread.fstate.f[1]); OFFSET(TASK_THREAD_F2, task_struct, thread.fstate.f[2]); diff --git a/arch/riscv/kernel/entry.S b/arch/riscv/kernel/entry.S index 33a5a9f2a0d4..68c99124ea55 100644 --- a/arch/riscv/kernel/entry.S +++ b/arch/riscv/kernel/entry.S @@ -147,6 +147,20 @@ SYM_CODE_START(handle_exception) REG_L s0, TASK_TI_USER_SP(tp) csrrc s1, CSR_STATUS, t0 + /* + * If previous mode was U, capture shadow stack pointer and save it away + * Zero CSR_SSP at the same time for sanitization. + */ + ALTERNATIVE("nop; nop; nop; nop", + __stringify( \ + andi s2, s1, SR_SPP; \ + bnez s2, skip_ssp_save; \ + csrrw s2, CSR_SSP, x0; \ + REG_S s2, TASK_TI_USER_SSP(tp); \ + skip_ssp_save:), + 0, + RISCV_ISA_EXT_ZICFISS, + CONFIG_RISCV_USER_CFI) csrr s2, CSR_EPC csrr s3, CSR_TVAL csrr s4, CSR_CAUSE @@ -236,6 +250,18 @@ SYM_CODE_START_NOALIGN(ret_from_exception) * structures again. */ csrw CSR_SCRATCH, tp + + /* + * Going back to U mode, restore shadow stack pointer + */ + ALTERNATIVE("nop; nop", + __stringify( \ + REG_L s3, TASK_TI_USER_SSP(tp); \ + csrw CSR_SSP, s3), + 0, + RISCV_ISA_EXT_ZICFISS, + CONFIG_RISCV_USER_CFI) + 1: #ifdef CONFIG_RISCV_ISA_V_PREEMPTIVE move a0, sp