linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Deepak Gupta <debug@rivosinc.com>
To: "Thomas Gleixner" <tglx@linutronix.de>,
	"Ingo Molnar" <mingo@redhat.com>,
	"Borislav Petkov" <bp@alien8.de>,
	"Dave Hansen" <dave.hansen@linux.intel.com>,
	x86@kernel.org, "H. Peter Anvin" <hpa@zytor.com>,
	"Andrew Morton" <akpm@linux-foundation.org>,
	"Liam R. Howlett" <Liam.Howlett@oracle.com>,
	"Vlastimil Babka" <vbabka@suse.cz>,
	"Lorenzo Stoakes" <lorenzo.stoakes@oracle.com>,
	"Paul Walmsley" <paul.walmsley@sifive.com>,
	"Palmer Dabbelt" <palmer@dabbelt.com>,
	"Albert Ou" <aou@eecs.berkeley.edu>,
	"Conor Dooley" <conor@kernel.org>,
	"Rob Herring" <robh@kernel.org>,
	"Krzysztof Kozlowski" <krzk+dt@kernel.org>,
	"Arnd Bergmann" <arnd@arndb.de>,
	"Christian Brauner" <brauner@kernel.org>,
	"Peter Zijlstra" <peterz@infradead.org>,
	"Oleg Nesterov" <oleg@redhat.com>,
	"Eric Biederman" <ebiederm@xmission.com>,
	"Kees Cook" <kees@kernel.org>, "Jonathan Corbet" <corbet@lwn.net>,
	"Shuah Khan" <shuah@kernel.org>, "Jann Horn" <jannh@google.com>,
	"Conor Dooley" <conor+dt@kernel.org>,
	"Miguel Ojeda" <ojeda@kernel.org>,
	"Alex Gaynor" <alex.gaynor@gmail.com>,
	"Boqun Feng" <boqun.feng@gmail.com>,
	"Gary Guo" <gary@garyguo.net>,
	"Björn Roy Baron" <bjorn3_gh@protonmail.com>,
	"Benno Lossin" <benno.lossin@proton.me>,
	"Andreas Hindborg" <a.hindborg@kernel.org>,
	"Alice Ryhl" <aliceryhl@google.com>,
	"Trevor Gross" <tmgross@umich.edu>
Cc: linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org,
	linux-mm@kvack.org, linux-riscv@lists.infradead.org,
	devicetree@vger.kernel.org, linux-arch@vger.kernel.org,
	linux-doc@vger.kernel.org, linux-kselftest@vger.kernel.org,
	alistair.francis@wdc.com, richard.henderson@linaro.org,
	jim.shu@sifive.com, andybnac@gmail.com, kito.cheng@sifive.com,
	charlie@rivosinc.com, atishp@rivosinc.com, evan@rivosinc.com,
	cleger@rivosinc.com, alexghiti@rivosinc.com,
	samitolvanen@google.com, broonie@kernel.org,
	rick.p.edgecombe@intel.com, rust-for-linux@vger.kernel.org,
	Zong Li <zong.li@sifive.com>
Subject: Re: [PATCH v16 23/27] arch/riscv: compile vdso with landing pad
Date: Thu, 22 May 2025 23:01:00 -0700	[thread overview]
Message-ID: <aDAPHHN0yRgmqSOI@debug.ba.rivosinc.com> (raw)
In-Reply-To: <20250522-v5_user_cfi_series-v16-23-64f61a35eee7@rivosinc.com>

On the topic of vDSO generation, I wanted to have a discussion thread. So
I'll use this patch and create a discussion thread.

Binaries in address space can call into vDSO and thus in order to have
homogenous cfi policies, vDSO is also compiled with cfi extensions enabled.
Thus it has shadow stack and landing pad instructions in it. Shadow stack
instructions encodings are from zimop/zcmop encodings while landing pad is
from HINT space of `auipc x0, imm`. Thus landing pad is truly backward
compatible with existing and future hardware both.

zimop/zcmop encodings are illegal instruction on existing hardware and any
future hardware that will not implement zimop/zcmop encodings. RVA23 profile
mandates zimop/zcmop encodings and thus any RVA23 compatible hardware should
be compatible with libraries (including vDSOs) with zimop/zcmop instructions
in them.

Kernel which is built doesn't know upfront which hardware it is going to run
on. It can be placed on top of a existing hardware, RVA23 compatible hardware
or any future hardware which is not RVA23 compatible but has not implemented
zimop/zcmop extensions. Question is should kernel be building two different
vDSOs (one with cfi/shadow stack instructions compiled and another without
cfi instructions inthem) and expose the one depending on underlying CPU
supports zimop/zcmop or not.

My initial hunch was to go with two different vDSOs in kernel and expose only
one depending on whether zimop/zcmop is implemented by platform or not.

However as ziciflp and zicfiss toolchain support is trickling into gnu-
toolchain, shadow stack instructions are part of libgcc and all small object
files that gets generated as part of toolchain creation (and eventually libc
too). So eventually anyone running on a hardware without zimop/zcmop must be
first building toolchain from scratch in order to build userspace rootfs and
later packages. This sounds like a significant chunk of work and at that point
they might as well just build kernel without `CONFIG_RISCV_USER_CFI` and should
get vDSO without any cfi instructions in them.

Thus I did not decide to provide multi-vDSO support in kernel considering it a
futile exercise. I wanted to put my thought process here so that there is some
discussion on this.

On Thu, May 22, 2025 at 10:31:26PM -0700, Deepak Gupta wrote:
>From: Jim Shu <jim.shu@sifive.com>
>
>user mode tasks compiled with zicfilp may call indirectly into vdso (like
>hwprobe indirect calls). Add landing pad compile support in vdso. vdso
>with landing pad in it will be nop for tasks which have not enabled
>landing pad.
>This patch allows to run user mode tasks with cfi eanbled and do no harm.
>
>Future work can be done on this to do below
> - labeled landing pad on vdso functions (whenever labeling support shows
>   up in gnu-toolchain)
> - emit shadow stack instructions only in vdso compiled objects as part of
>   kernel compile.
>
>Signed-off-by: Jim Shu <jim.shu@sifive.com>
>Reviewed-by: Zong Li <zong.li@sifive.com>
>Signed-off-by: Deepak Gupta <debug@rivosinc.com>
>---
> arch/riscv/Makefile                   |  5 +++-
> arch/riscv/include/asm/assembler.h    | 44 +++++++++++++++++++++++++++++++++++
> arch/riscv/kernel/vdso/Makefile       |  6 +++++
> arch/riscv/kernel/vdso/flush_icache.S |  4 ++++
> arch/riscv/kernel/vdso/getcpu.S       |  4 ++++
> arch/riscv/kernel/vdso/rt_sigreturn.S |  4 ++++
> arch/riscv/kernel/vdso/sys_hwprobe.S  |  4 ++++
> 7 files changed, 70 insertions(+), 1 deletion(-)
>
>diff --git a/arch/riscv/Makefile b/arch/riscv/Makefile
>index 539d2aef5cab..c2dd09bb9db3 100644
>--- a/arch/riscv/Makefile
>+++ b/arch/riscv/Makefile
>@@ -88,9 +88,12 @@ riscv-march-$(CONFIG_TOOLCHAIN_HAS_ZACAS) := $(riscv-march-y)_zacas
> # Check if the toolchain supports Zabha
> riscv-march-$(CONFIG_TOOLCHAIN_HAS_ZABHA) := $(riscv-march-y)_zabha
>
>+KBUILD_BASE_ISA = -march=$(shell echo $(riscv-march-y) | sed -E 's/(rv32ima|rv64ima)fd([^v_]*)v?/\1\2/')
>+export KBUILD_BASE_ISA
>+
> # Remove F,D,V from isa string for all. Keep extensions between "fd" and "v" by
> # matching non-v and non-multi-letter extensions out with the filter ([^v_]*)
>-KBUILD_CFLAGS += -march=$(shell echo $(riscv-march-y) | sed -E 's/(rv32ima|rv64ima)fd([^v_]*)v?/\1\2/')
>+KBUILD_CFLAGS += $(KBUILD_BASE_ISA)
>
> KBUILD_AFLAGS += -march=$(riscv-march-y)
>
>diff --git a/arch/riscv/include/asm/assembler.h b/arch/riscv/include/asm/assembler.h
>index 44b1457d3e95..a058ea5e9c58 100644
>--- a/arch/riscv/include/asm/assembler.h
>+++ b/arch/riscv/include/asm/assembler.h
>@@ -80,3 +80,47 @@
> 	.endm
>
> #endif	/* __ASM_ASSEMBLER_H */
>+
>+#if defined(CONFIG_RISCV_USER_CFI) && (__riscv_xlen == 64)
>+.macro vdso_lpad
>+lpad 0
>+.endm
>+#else
>+.macro vdso_lpad
>+.endm
>+#endif
>+
>+/*
>+ * This macro emits a program property note section identifying
>+ * architecture features which require special handling, mainly for
>+ * use in assembly files included in the VDSO.
>+ */
>+#define NT_GNU_PROPERTY_TYPE_0  5
>+#define GNU_PROPERTY_RISCV_FEATURE_1_AND 0xc0000000
>+
>+#define GNU_PROPERTY_RISCV_FEATURE_1_ZICFILP      (1U << 0)
>+#define GNU_PROPERTY_RISCV_FEATURE_1_ZICFISS      (1U << 1)
>+
>+#if defined(CONFIG_RISCV_USER_CFI) && (__riscv_xlen == 64)
>+#define GNU_PROPERTY_RISCV_FEATURE_1_DEFAULT \
>+	(GNU_PROPERTY_RISCV_FEATURE_1_ZICFILP)
>+#endif
>+
>+#ifdef GNU_PROPERTY_RISCV_FEATURE_1_DEFAULT
>+.macro emit_riscv_feature_1_and, feat = GNU_PROPERTY_RISCV_FEATURE_1_DEFAULT
>+	.pushsection .note.gnu.property, "a"
>+	.p2align        3
>+	.word           4
>+	.word           16
>+	.word           NT_GNU_PROPERTY_TYPE_0
>+	.asciz          "GNU"
>+	.word           GNU_PROPERTY_RISCV_FEATURE_1_AND
>+	.word           4
>+	.word           \feat
>+	.word           0
>+	.popsection
>+.endm
>+#else
>+.macro emit_riscv_feature_1_and, feat = 0
>+.endm
>+#endif
>diff --git a/arch/riscv/kernel/vdso/Makefile b/arch/riscv/kernel/vdso/Makefile
>index ad73607abc28..441c5431d27e 100644
>--- a/arch/riscv/kernel/vdso/Makefile
>+++ b/arch/riscv/kernel/vdso/Makefile
>@@ -13,12 +13,18 @@ vdso-syms += flush_icache
> vdso-syms += hwprobe
> vdso-syms += sys_hwprobe
>
>+ifdef CONFIG_RISCV_USER_CFI
>+LPAD_MARCH = _zicfilp_zicfiss -fcf-protection=full
>+endif
>+
> # Files to link into the vdso
> obj-vdso = $(patsubst %, %.o, $(vdso-syms)) note.o
>
> ccflags-y := -fno-stack-protector
> ccflags-y += -DDISABLE_BRANCH_PROFILING
> ccflags-y += -fno-builtin
>+ccflags-y += $(KBUILD_BASE_ISA)$(LPAD_MARCH)
>+asflags-y += $(KBUILD_BASE_ISA)$(LPAD_MARCH)
>
> ifneq ($(c-gettimeofday-y),)
>   CFLAGS_vgettimeofday.o += -fPIC -include $(c-gettimeofday-y)
>diff --git a/arch/riscv/kernel/vdso/flush_icache.S b/arch/riscv/kernel/vdso/flush_icache.S
>index 8f884227e8bc..e4c56970905e 100644
>--- a/arch/riscv/kernel/vdso/flush_icache.S
>+++ b/arch/riscv/kernel/vdso/flush_icache.S
>@@ -5,11 +5,13 @@
>
> #include <linux/linkage.h>
> #include <asm/unistd.h>
>+#include <asm/assembler.h>
>
> 	.text
> /* int __vdso_flush_icache(void *start, void *end, unsigned long flags); */
> SYM_FUNC_START(__vdso_flush_icache)
> 	.cfi_startproc
>+	vdso_lpad
> #ifdef CONFIG_SMP
> 	li a7, __NR_riscv_flush_icache
> 	ecall
>@@ -20,3 +22,5 @@ SYM_FUNC_START(__vdso_flush_icache)
> 	ret
> 	.cfi_endproc
> SYM_FUNC_END(__vdso_flush_icache)
>+
>+emit_riscv_feature_1_and
>diff --git a/arch/riscv/kernel/vdso/getcpu.S b/arch/riscv/kernel/vdso/getcpu.S
>index 9c1bd531907f..5c1ecc4e1465 100644
>--- a/arch/riscv/kernel/vdso/getcpu.S
>+++ b/arch/riscv/kernel/vdso/getcpu.S
>@@ -5,14 +5,18 @@
>
> #include <linux/linkage.h>
> #include <asm/unistd.h>
>+#include <asm/assembler.h>
>
> 	.text
> /* int __vdso_getcpu(unsigned *cpu, unsigned *node, void *unused); */
> SYM_FUNC_START(__vdso_getcpu)
> 	.cfi_startproc
>+	vdso_lpad
> 	/* For now, just do the syscall. */
> 	li a7, __NR_getcpu
> 	ecall
> 	ret
> 	.cfi_endproc
> SYM_FUNC_END(__vdso_getcpu)
>+
>+emit_riscv_feature_1_and
>diff --git a/arch/riscv/kernel/vdso/rt_sigreturn.S b/arch/riscv/kernel/vdso/rt_sigreturn.S
>index 3dc022aa8931..e82987dc3739 100644
>--- a/arch/riscv/kernel/vdso/rt_sigreturn.S
>+++ b/arch/riscv/kernel/vdso/rt_sigreturn.S
>@@ -5,12 +5,16 @@
>
> #include <linux/linkage.h>
> #include <asm/unistd.h>
>+#include <asm/assembler.h>
>
> 	.text
> SYM_FUNC_START(__vdso_rt_sigreturn)
> 	.cfi_startproc
> 	.cfi_signal_frame
>+	vdso_lpad
> 	li a7, __NR_rt_sigreturn
> 	ecall
> 	.cfi_endproc
> SYM_FUNC_END(__vdso_rt_sigreturn)
>+
>+emit_riscv_feature_1_and
>diff --git a/arch/riscv/kernel/vdso/sys_hwprobe.S b/arch/riscv/kernel/vdso/sys_hwprobe.S
>index 77e57f830521..f1694451a60c 100644
>--- a/arch/riscv/kernel/vdso/sys_hwprobe.S
>+++ b/arch/riscv/kernel/vdso/sys_hwprobe.S
>@@ -3,13 +3,17 @@
>
> #include <linux/linkage.h>
> #include <asm/unistd.h>
>+#include <asm/assembler.h>
>
> .text
> SYM_FUNC_START(riscv_hwprobe)
> 	.cfi_startproc
>+	vdso_lpad
> 	li a7, __NR_riscv_hwprobe
> 	ecall
> 	ret
>
> 	.cfi_endproc
> SYM_FUNC_END(riscv_hwprobe)
>+
>+emit_riscv_feature_1_and
>
>-- 
>2.43.0
>


  reply	other threads:[~2025-05-23  6:01 UTC|newest]

Thread overview: 34+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-05-23  5:31 [PATCH v16 00/27] riscv control-flow integrity for usermode Deepak Gupta
2025-05-23  5:31 ` [PATCH v16 01/27] mm: VM_SHADOW_STACK definition for riscv Deepak Gupta
2025-05-23  5:31 ` [PATCH v16 02/27] dt-bindings: riscv: zicfilp and zicfiss in dt-bindings (extensions.yaml) Deepak Gupta
2025-05-23  5:31 ` [PATCH v16 03/27] riscv: zicfiss / zicfilp enumeration Deepak Gupta
2025-05-23  5:31 ` [PATCH v16 04/27] riscv: zicfiss / zicfilp extension csr and bit definitions Deepak Gupta
2025-05-23  5:31 ` [PATCH v16 05/27] riscv: usercfi state for task and save/restore of CSR_SSP on trap entry/exit Deepak Gupta
2025-05-23  5:31 ` [PATCH v16 06/27] riscv/mm : ensure PROT_WRITE leads to VM_READ | VM_WRITE Deepak Gupta
2025-05-23  5:31 ` [PATCH v16 07/27] riscv mm: manufacture shadow stack pte Deepak Gupta
2025-05-23  5:31 ` [PATCH v16 08/27] riscv mmu: teach pte_mkwrite to manufacture shadow stack PTEs Deepak Gupta
2025-05-23  5:31 ` [PATCH v16 09/27] riscv mmu: write protect and shadow stack Deepak Gupta
2025-05-23  5:31 ` [PATCH v16 10/27] riscv/mm: Implement map_shadow_stack() syscall Deepak Gupta
2025-05-23  5:31 ` [PATCH v16 11/27] riscv/shstk: If needed allocate a new shadow stack on clone Deepak Gupta
2025-05-23  5:31 ` [PATCH v16 12/27] riscv: Implements arch agnostic shadow stack prctls Deepak Gupta
2025-05-23  5:31 ` [PATCH v16 13/27] prctl: arch-agnostic prctl for indirect branch tracking Deepak Gupta
2025-05-23  5:31 ` [PATCH v16 14/27] riscv: Implements arch agnostic indirect branch tracking prctls Deepak Gupta
2025-05-23 23:06   ` kernel test robot
2025-05-23  5:31 ` [PATCH v16 15/27] riscv/traps: Introduce software check exception Deepak Gupta
2025-05-23  5:31 ` [PATCH v16 16/27] riscv: signal: abstract header saving for setup_sigcontext Deepak Gupta
2025-05-23  5:31 ` [PATCH v16 17/27] riscv/signal: save and restore of shadow stack for signal Deepak Gupta
2025-05-23  5:31 ` [PATCH v16 18/27] riscv/kernel: update __show_regs to print shadow stack register Deepak Gupta
2025-05-23  5:31 ` [PATCH v16 19/27] riscv/ptrace: riscv cfi status and state via ptrace and in core files Deepak Gupta
2025-05-23  5:31 ` [PATCH v16 20/27] riscv/hwprobe: zicfilp / zicfiss enumeration in hwprobe Deepak Gupta
2025-05-23  5:31 ` [PATCH v16 21/27] riscv: kernel command line option to opt out of user cfi Deepak Gupta
2025-05-23  5:31 ` [PATCH v16 22/27] riscv: enable kernel access to shadow stack memory via FWFT sbi call Deepak Gupta
2025-05-23  5:31 ` [PATCH v16 23/27] arch/riscv: compile vdso with landing pad Deepak Gupta
2025-05-23  6:01   ` Deepak Gupta [this message]
2025-05-23  5:31 ` [PATCH v16 24/27] riscv: create a config for shadow stack and landing pad instr support Deepak Gupta
2025-05-23  5:31 ` [PATCH v16 25/27] riscv: Documentation for landing pad / indirect branch tracking Deepak Gupta
2025-05-23  5:31 ` [PATCH v16 26/27] riscv: Documentation for shadow stack on riscv Deepak Gupta
2025-05-23  5:31 ` [PATCH v16 27/27] kselftest/riscv: kselftest for user mode cfi Deepak Gupta
2025-05-23  8:22   ` Charlie Jenkins
2025-05-23  8:34     ` Charlie Jenkins
2025-05-23 17:42       ` Charlie Jenkins
2025-05-23  5:42 ` [PATCH v16 00/27] riscv control-flow integrity for usermode Deepak Gupta

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=aDAPHHN0yRgmqSOI@debug.ba.rivosinc.com \
    --to=debug@rivosinc.com \
    --cc=Liam.Howlett@oracle.com \
    --cc=a.hindborg@kernel.org \
    --cc=akpm@linux-foundation.org \
    --cc=alex.gaynor@gmail.com \
    --cc=alexghiti@rivosinc.com \
    --cc=aliceryhl@google.com \
    --cc=alistair.francis@wdc.com \
    --cc=andybnac@gmail.com \
    --cc=aou@eecs.berkeley.edu \
    --cc=arnd@arndb.de \
    --cc=atishp@rivosinc.com \
    --cc=benno.lossin@proton.me \
    --cc=bjorn3_gh@protonmail.com \
    --cc=boqun.feng@gmail.com \
    --cc=bp@alien8.de \
    --cc=brauner@kernel.org \
    --cc=broonie@kernel.org \
    --cc=charlie@rivosinc.com \
    --cc=cleger@rivosinc.com \
    --cc=conor+dt@kernel.org \
    --cc=conor@kernel.org \
    --cc=corbet@lwn.net \
    --cc=dave.hansen@linux.intel.com \
    --cc=devicetree@vger.kernel.org \
    --cc=ebiederm@xmission.com \
    --cc=evan@rivosinc.com \
    --cc=gary@garyguo.net \
    --cc=hpa@zytor.com \
    --cc=jannh@google.com \
    --cc=jim.shu@sifive.com \
    --cc=kees@kernel.org \
    --cc=kito.cheng@sifive.com \
    --cc=krzk+dt@kernel.org \
    --cc=linux-arch@vger.kernel.org \
    --cc=linux-doc@vger.kernel.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-kselftest@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=linux-riscv@lists.infradead.org \
    --cc=lorenzo.stoakes@oracle.com \
    --cc=mingo@redhat.com \
    --cc=ojeda@kernel.org \
    --cc=oleg@redhat.com \
    --cc=palmer@dabbelt.com \
    --cc=paul.walmsley@sifive.com \
    --cc=peterz@infradead.org \
    --cc=richard.henderson@linaro.org \
    --cc=rick.p.edgecombe@intel.com \
    --cc=robh@kernel.org \
    --cc=rust-for-linux@vger.kernel.org \
    --cc=samitolvanen@google.com \
    --cc=shuah@kernel.org \
    --cc=tglx@linutronix.de \
    --cc=tmgross@umich.edu \
    --cc=vbabka@suse.cz \
    --cc=x86@kernel.org \
    --cc=zong.li@sifive.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).