lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <D8LESTM58PV0.7F6M6XYSL4BU@ventanamicro.com>
Date: Thu, 20 Mar 2025 22:25:30 +0100
From: Radim Krčmář <rkrcmar@...tanamicro.com>
To: "Deepak Gupta" <debug@...osinc.com>, "Thomas Gleixner"
 <tglx@...utronix.de>, "Ingo Molnar" <mingo@...hat.com>, "Borislav Petkov"
 <bp@...en8.de>, "Dave Hansen" <dave.hansen@...ux.intel.com>,
 <x86@...nel.org>, "H. Peter Anvin" <hpa@...or.com>, "Andrew Morton"
 <akpm@...ux-foundation.org>, "Liam R. Howlett" <Liam.Howlett@...cle.com>,
 "Vlastimil Babka" <vbabka@...e.cz>, "Lorenzo Stoakes"
 <lorenzo.stoakes@...cle.com>, "Paul Walmsley" <paul.walmsley@...ive.com>,
 "Palmer Dabbelt" <palmer@...belt.com>, "Albert Ou" <aou@...s.berkeley.edu>,
 "Conor Dooley" <conor@...nel.org>, "Rob Herring" <robh@...nel.org>,
 "Krzysztof Kozlowski" <krzk+dt@...nel.org>, "Arnd Bergmann"
 <arnd@...db.de>, "Christian Brauner" <brauner@...nel.org>, "Peter Zijlstra"
 <peterz@...radead.org>, "Oleg Nesterov" <oleg@...hat.com>, "Eric Biederman"
 <ebiederm@...ssion.com>, "Kees Cook" <kees@...nel.org>, "Jonathan Corbet"
 <corbet@....net>, "Shuah Khan" <shuah@...nel.org>, "Jann Horn"
 <jannh@...gle.com>, "Conor Dooley" <conor+dt@...nel.org>
Cc: <linux-kernel@...r.kernel.org>, <linux-fsdevel@...r.kernel.org>,
 <linux-mm@...ck.org>, <linux-riscv@...ts.infradead.org>,
 <devicetree@...r.kernel.org>, <linux-arch@...r.kernel.org>,
 <linux-doc@...r.kernel.org>, <linux-kselftest@...r.kernel.org>,
 <alistair.francis@....com>, <richard.henderson@...aro.org>,
 <jim.shu@...ive.com>, <andybnac@...il.com>, <kito.cheng@...ive.com>,
 <charlie@...osinc.com>, <atishp@...osinc.com>, <evan@...osinc.com>,
 <cleger@...osinc.com>, <alexghiti@...osinc.com>, <samitolvanen@...gle.com>,
 <broonie@...nel.org>, <rick.p.edgecombe@...el.com>, "Zong Li"
 <zong.li@...ive.com>, "linux-riscv"
 <linux-riscv-bounces@...ts.infradead.org>
Subject: Re: [PATCH v12 25/28] riscv: create a config for shadow stack and
 landing pad instr support

2025-03-14T14:39:44-07:00, Deepak Gupta <debug@...osinc.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@...ive.com>
> Signed-off-by: Deepak Gupta <debug@...osinc.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.

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ