| Message ID | 20250314-v5_user_cfi_series-v12-22-e51202b53138@rivosinc.com (mailing list archive) |
|---|---|
| State | New |
| Headers | show |
| Series | riscv control-flow integrity for usermode | expand |
| Context | Check | Description |
|---|---|---|
| bjorn/pre-ci_am | success | Success |
| bjorn/build-rv32-defconfig | success | build-rv32-defconfig |
| bjorn/build-rv64-clang-allmodconfig | success | build-rv64-clang-allmodconfig |
| bjorn/build-rv64-gcc-allmodconfig | success | build-rv64-gcc-allmodconfig |
| bjorn/build-rv64-nommu-k210-defconfig | fail | build-rv64-nommu-k210-defconfig |
| bjorn/build-rv64-nommu-k210-virt | fail | build-rv64-nommu-k210-virt |
| bjorn/checkpatch | success | checkpatch |
| bjorn/dtb-warn-rv64 | success | dtb-warn-rv64 |
| bjorn/header-inline | success | header-inline |
| bjorn/kdoc | success | kdoc |
| bjorn/module-param | success | module-param |
| bjorn/verify-fixes | success | verify-fixes |
| bjorn/verify-signedoff | success | verify-signedoff |
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? > In future when kernel shadow stacks are enabled for linux kernel, it must > be enabled as early as possible for better coverage and prevent imbalance > between regular stack and shadow stack. After `relocate_enable_mmu` has > been done, this is as early as possible it can enabled. > > Reviewed-by: Zong Li <zong.li@sifive.com> > Signed-off-by: Deepak Gupta <debug@rivosinc.com> > --- > 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_FWFT > + li a6, SBI_EXT_FWFT_SET > + li a0, SBI_FWFT_SHADOW_STACK > + li a1, 1 /* enable supervisor to access shadow stack access */ > + li a2, SBI_FWFT_SET_FLAG_LOCK > + ecall I think the ecall can fail even on machines that have Zicfiss, so it would be good to disable user shadow stack if that happens.
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. A kernel alternate mapping can be created, but that 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. 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. > > > In future when kernel shadow stacks are enabled for linux kernel, it must > > be enabled as early as possible for better coverage and prevent imbalance > > between regular stack and shadow stack. After `relocate_enable_mmu` has > > been done, this is as early as possible it can enabled. > > > > Reviewed-by: Zong Li <zong.li@sifive.com> > > Signed-off-by: Deepak Gupta <debug@rivosinc.com> > > --- > > 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_FWFT > > + li a6, SBI_EXT_FWFT_SET > > + li a0, SBI_FWFT_SHADOW_STACK > > + li a1, 1 /* enable supervisor to access shadow stack access */ > > + li a2, SBI_FWFT_SET_FLAG_LOCK > > + ecall > > I think the ecall can fail even on machines that have Zicfiss, so it > would be good to disable user shadow stack if that happens.
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, but > that 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_FWFT >> > + li a6, SBI_EXT_FWFT_SET >> > + li a0, SBI_FWFT_SHADOW_STACK >> > + li a1, 1 /* enable supervisor to access shadow stack access */ >> > + li a2, SBI_FWFT_SET_FLAG_LOCK >> > + ecall >> >> I think the ecall can fail even on machines that have Zicfiss, so it >> would be good to disable user shadow stack if that happens.
diff --git a/arch/riscv/kernel/asm-offsets.c b/arch/riscv/kernel/asm-offsets.c index 0c188aaf3925..21f99d5757b6 100644 --- a/arch/riscv/kernel/asm-offsets.c +++ b/arch/riscv/kernel/asm-offsets.c @@ -515,4 +515,8 @@ void asm_offsets(void) DEFINE(FREGS_A6, offsetof(struct __arch_ftrace_regs, a6)); DEFINE(FREGS_A7, offsetof(struct __arch_ftrace_regs, a7)); #endif + DEFINE(SBI_EXT_FWFT, SBI_EXT_FWFT); + DEFINE(SBI_EXT_FWFT_SET, SBI_EXT_FWFT_SET); + DEFINE(SBI_FWFT_SHADOW_STACK, SBI_FWFT_SHADOW_STACK); + DEFINE(SBI_FWFT_SET_FLAG_LOCK, SBI_FWFT_SET_FLAG_LOCK); } diff --git a/arch/riscv/kernel/head.S b/arch/riscv/kernel/head.S index 356d5397b2a2..6244408ca917 100644 --- a/arch/riscv/kernel/head.S +++ b/arch/riscv/kernel/head.S @@ -164,6 +164,12 @@ secondary_start_sbi: call relocate_enable_mmu #endif call .Lsetup_trap_vector + li a7, SBI_EXT_FWFT + li a6, SBI_EXT_FWFT_SET + li a0, SBI_FWFT_SHADOW_STACK + li a1, 1 /* enable supervisor to access shadow stack access */ + li a2, SBI_FWFT_SET_FLAG_LOCK + ecall scs_load_current call smp_callin #endif /* CONFIG_SMP */ @@ -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_FWFT + li a6, SBI_EXT_FWFT_SET + li a0, SBI_FWFT_SHADOW_STACK + li a1, 1 /* enable supervisor to access shadow stack access */ + li a2, SBI_FWFT_SET_FLAG_LOCK + ecall scs_load_current #ifdef CONFIG_KASAN