| Message ID | 20250314-v5_user_cfi_series-v12-25-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:44-07:00, Deepak Gupta <debug@rivosinc.com>: > 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@sifive.com> > Signed-off-by: Deepak Gupta <debug@rivosinc.com> > --- > 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.
On Thu, Mar 20, 2025 at 2:25 PM Radim Krčmář <rkrcmar@ventanamicro.com> wrote: > > 2025-03-14T14:39:44-07:00, Deepak Gupta <debug@rivosinc.com>: > > 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@sifive.com> > > Signed-off-by: Deepak Gupta <debug@rivosinc.com> > > --- > > 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. From organizing patches in the patch series, shadow stack and landing pad patches do not cross into each other and are different from each other except dt-bindings, hwprobe, csr definitions. I can separate them out as well if that's desired. Furthermore, I do not see an implementation only implementing zicfilp while not implementing zicfiss. There is a case of a nommu case where only zicfilp might be implemented and no zicfiss. However that's the case which is anyways riscv linux kernel is not actively being tested. IIRC, it was (nommu linux) considered to be phased out/not supported as well. We could have two different configs but I don't see what would serve apart from the ability to build support for landing pad and shadow stack differently. As I said from a usability point of view both features are complimenting to each other rather than standing out alone and providing full protection. A kernel is built with support for enabling both features or none. Sure user can use either of the prctl to enable either of the features in whatever combination they see fit.
2025-03-20T15:29:55-07:00, Deepak Gupta <debug@rivosinc.com>: > On Thu, Mar 20, 2025 at 2:25 PM Radim Krčmář <rkrcmar@ventanamicro.com> wrote: >> >> 2025-03-14T14:39:44-07:00, Deepak Gupta <debug@rivosinc.com>: >> > 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@sifive.com> >> > Signed-off-by: Deepak Gupta <debug@rivosinc.com> >> > --- >> > 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. > > From organizing patches in the patch series, shadow stack and landing > pad patches do not cross into each other and are different from each > other except dt-bindings, hwprobe, csr definitions. I can separate them > out as well if that's desired. It would be my preference, but it's the maintainer's call. I think that landing pads could be merged earlier if they were posted separately, but this series is already on v12, so I don't want to force anything. > Furthermore, I do not see an implementation only implementing zicfilp > while not implementing zicfiss. There is a case of a nommu case where > only zicfilp might be implemented and no zicfiss. However that's the case > which is anyways riscv linux kernel is not actively being tested. IIRC, > it was (nommu linux) considered to be phased out/not supported as well. > > We could have two different configs but I don't see what would serve > apart from the ability to build support for landing pad and shadow stack > differently. As I said from a usability point of view both features > are complimenting > to each other rather than standing out alone and providing full protection. > > A kernel is built with support for enabling both features or none. Sure user > can use either of the prctl to enable either of the features in whatever > combination they see fit. Yeah, it will be rare, but if for some reason one feature cannot be used, then having just one is better than none. We can easily add compile options later and if we start with separate kernel parameters, then the users won't even notice a difference.
diff --git a/arch/riscv/Kconfig b/arch/riscv/Kconfig index 7612c52e9b1e..0a2e50f056e8 100644 --- a/arch/riscv/Kconfig +++ b/arch/riscv/Kconfig @@ -250,6 +250,26 @@ config ARCH_HAS_BROKEN_DWARF5 # https://github.com/llvm/llvm-project/commit/7ffabb61a5569444b5ac9322e22e5471cc5e4a77 depends on LD_IS_LLD && LLD_VERSION < 180000 +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 + config ARCH_MMAP_RND_BITS_MIN default 18 if 64BIT default 8