2025-03-20T15:42:44-07:00, Deepak Gupta debug@rivosinc.com:
On Thu, Mar 20, 2025 at 3:10 PM Radim Krčmář rkrcmar@ventanamicro.com wrote:
2025-03-14T14:39:41-07:00, Deepak Gupta debug@rivosinc.com:
Kernel will have to perform shadow stack operations on user shadow stack. Like during signal delivery and sigreturn, shadow stack token must be created and validated respectively. Thus shadow stack access for kernel must be enabled.
Why can't kernel access the user shadow stack through an aliased WR mapping?
It can, although that opens up a can of worms. If this alternating mapping is user mode then ensuring that another threat in userspace can't write to this address in this window of signal handling.
Right, it must not be user mode.
A kernel alternate mapping can be created, butthat can lead to all sorts of requirements of ensuring the page is pinned down. IIRC, It has been debated on x86 shadow stack merge time as well on how a flaky alias mapping approach can become and weaken the threat model it is supposed to protect against.
True.
Simply using `ssamoswap` is simple and serves the purpose. Enabling shadow stack access for the kernel doesn't have any adverse effect on the kernel.
Makes sense. We just depend on an extra feature, because we should consider the case when M-mode doesn't allow S-mode shadow stack, but S-mode can enable U-mode shadow stack:
diff --git a/arch/riscv/kernel/head.S b/arch/riscv/kernel/head.S @@ -320,6 +326,12 @@ SYM_CODE_START(_start_kernel) la tp, init_task la sp, init_thread_union + THREAD_SIZE addi sp, sp, -PT_SIZE_ON_STACK
li a7, SBI_EXT_FWFTli a6, SBI_EXT_FWFT_SETli a0, SBI_FWFT_SHADOW_STACKli a1, 1 /* enable supervisor to access shadow stack access */li a2, SBI_FWFT_SET_FLAG_LOCKecallI think the ecall can fail even on machines that have Zicfiss, so it would be good to disable user shadow stack if that happens.