On Thu, Mar 20, 2025 at 2:25 PM Radim Krčmář <rkrcmar@xxxxxxxxxxxxxxxx> wrote: > > 2025-03-14T14:39:44-07:00, Deepak Gupta <debug@xxxxxxxxxxxx>: > > This patch creates a config for shadow stack support and landing pad instr > > support. Shadow stack support and landing instr support can be enabled by > > selecting `CONFIG_RISCV_USER_CFI`. Selecting `CONFIG_RISCV_USER_CFI` wires > > up path to enumerate CPU support and if cpu support exists, kernel will > > support cpu assisted user mode cfi. > > > > If CONFIG_RISCV_USER_CFI is selected, select `ARCH_USES_HIGH_VMA_FLAGS`, > > `ARCH_HAS_USER_SHADOW_STACK` and DYNAMIC_SIGFRAME for riscv. > > > > Reviewed-by: Zong Li <zong.li@xxxxxxxxxx> > > Signed-off-by: Deepak Gupta <debug@xxxxxxxxxxxx> > > --- > > diff --git a/arch/riscv/Kconfig b/arch/riscv/Kconfig > > @@ -250,6 +250,26 @@ config ARCH_HAS_BROKEN_DWARF5 > > +config RISCV_USER_CFI > > + def_bool y > > + bool "riscv userspace control flow integrity" > > + depends on 64BIT && $(cc-option,-mabi=lp64 -march=rv64ima_zicfiss) > > + depends on RISCV_ALTERNATIVE > > + select ARCH_HAS_USER_SHADOW_STACK > > + select ARCH_USES_HIGH_VMA_FLAGS > > + select DYNAMIC_SIGFRAME > > + help > > + Provides CPU assisted control flow integrity to userspace tasks. > > + Control flow integrity is provided by implementing shadow stack for > > + backward edge and indirect branch tracking for forward edge in program. > > + Shadow stack protection is a hardware feature that detects function > > + return address corruption. This helps mitigate ROP attacks. > > + Indirect branch tracking enforces that all indirect branches must land > > + on a landing pad instruction else CPU will fault. This mitigates against > > + JOP / COP attacks. Applications must be enabled to use it, and old user- > > + space does not get protection "for free". > > + default y > > A high level question to kick off my review: > > Why are landing pads and shadow stacks merged together? > > Apart from adding build flexibility, we could also split the patches > into two isolated series, because the features are independent. Strictly from CPU extensions point of view they are independent features. Although from a usability point of view they complement each other. A user wanting to enable support for control flow integrity wouldn't be enabling only landing pad and leaving return flow open for an attacker and vice-versa. That's why I defined a single CONFIG for CFI.
