[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <aAnnbtABLTL81uEY@debug.ba.rivosinc.com>
Date: Thu, 24 Apr 2025 00:25:34 -0700
From: Deepak Gupta <debug@...osinc.com>
To: 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>,
Miguel Ojeda <ojeda@...nel.org>,
Alex Gaynor <alex.gaynor@...il.com>,
Boqun Feng <boqun.feng@...il.com>, Gary Guo <gary@...yguo.net>,
Björn Roy Baron <bjorn3_gh@...tonmail.com>,
Benno Lossin <benno.lossin@...ton.me>,
Andreas Hindborg <a.hindborg@...nel.org>,
Alice Ryhl <aliceryhl@...gle.com>, Trevor Gross <tmgross@...ch.edu>
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, rust-for-linux@...r.kernel.org,
Zong Li <zong.li@...ive.com>
Subject: Re: [PATCH v13 05/28] riscv: usercfi state for task and save/restore
of CSR_SSP on trap entry/exit
On Thu, Apr 24, 2025 at 12:20:20AM -0700, Deepak Gupta wrote:
>Carves out space in arch specific thread struct for cfi status and shadow
>stack in usermode on riscv.
>
>This patch does following
>- defines a new structure cfi_status with status bit for cfi feature
>- defines shadow stack pointer, base and size in cfi_status structure
>- defines offsets to new member fields in thread in asm-offsets.c
>- Saves and restore shadow stack pointer on trap entry (U --> S) and exit
> (S --> U)
>
>Shadow stack save/restore is gated on feature availiblity and implemented
>using alternative. CSR can be context switched in `switch_to` as well but
>soon as kernel shadow stack support gets rolled in, shadow stack pointer
>will need to be switched at trap entry/exit point (much like `sp`). It can
>be argued that kernel using shadow stack deployment scenario may not be as
>prevalant as user mode using this feature. But even if there is some
>minimal deployment of kernel shadow stack, that means that it needs to be
>supported. And thus save/restore of shadow stack pointer in entry.S instead
>of in `switch_to.h`.
>
>Reviewed-by: Charlie Jenkins <charlie@...osinc.com>
>Reviewed-by: Zong Li <zong.li@...ive.com>
>Reviewed-by: Alexandre Ghiti <alexghiti@...osinc.com>
>Signed-off-by: Deepak Gupta <debug@...osinc.com>
>---
> arch/riscv/include/asm/processor.h | 1 +
> arch/riscv/include/asm/thread_info.h | 3 +++
> arch/riscv/include/asm/usercfi.h | 24 ++++++++++++++++++++++++
> arch/riscv/kernel/asm-offsets.c | 4 ++++
> arch/riscv/kernel/entry.S | 23 +++++++++++++++++++++++
> 5 files changed, 55 insertions(+)
>
>diff --git a/arch/riscv/include/asm/processor.h b/arch/riscv/include/asm/processor.h
>index e3aba3336e63..d851bb5c6da0 100644
>--- a/arch/riscv/include/asm/processor.h
>+++ b/arch/riscv/include/asm/processor.h
>@@ -14,6 +14,7 @@
>
> #include <asm/ptrace.h>
> #include <asm/hwcap.h>
>+#include <asm/usercfi.h>
>
> #define arch_get_mmap_end(addr, len, flags) \
> ({ \
>diff --git a/arch/riscv/include/asm/thread_info.h b/arch/riscv/include/asm/thread_info.h
>index f5916a70879a..a0cfe00c2ca6 100644
>--- a/arch/riscv/include/asm/thread_info.h
>+++ b/arch/riscv/include/asm/thread_info.h
>@@ -62,6 +62,9 @@ struct thread_info {
> long user_sp; /* User stack pointer */
> int cpu;
> unsigned long syscall_work; /* SYSCALL_WORK_ flags */
>+#ifdef CONFIG_RISCV_USER_CFI
>+ struct cfi_status user_cfi_state;
>+#endif
> #ifdef CONFIG_SHADOW_CALL_STACK
> void *scs_base;
> void *scs_sp;
>diff --git a/arch/riscv/include/asm/usercfi.h b/arch/riscv/include/asm/usercfi.h
>new file mode 100644
>index 000000000000..5f2027c51917
>--- /dev/null
>+++ b/arch/riscv/include/asm/usercfi.h
>@@ -0,0 +1,24 @@
>+/* SPDX-License-Identifier: GPL-2.0
>+ * Copyright (C) 2024 Rivos, Inc.
>+ * Deepak Gupta <debug@...osinc.com>
>+ */
>+#ifndef _ASM_RISCV_USERCFI_H
>+#define _ASM_RISCV_USERCFI_H
>+
>+#ifndef __ASSEMBLY__
>+#include <linux/types.h>
>+
>+#ifdef CONFIG_RISCV_USER_CFI
>+struct cfi_status {
>+ unsigned long ubcfi_en : 1; /* Enable for backward cfi. */
>+ unsigned long rsvd : ((sizeof(unsigned long) * 8) - 1);
>+ unsigned long user_shdw_stk; /* Current user shadow stack pointer */
>+ unsigned long shdw_stk_base; /* Base address of shadow stack */
>+ unsigned long shdw_stk_size; /* size of shadow stack */
>+};
I didn't change this part yet. There are two comments from Radim here
1) Separate state of enabling/lock status from shadow stack pointer.
Same goes for landing pad in later patches. I am arguing that since
thread_info is already occupies two cachelines and there isn't any
effort to manage it within single cacheline, I am not sure if it's worth
the effort. Most likely comment is stale or doesn't have backed up data
behind it. Furthermore whenever state of enabling is accessed, most likely
shadow stack pointer, base pointer or size of shaodw stack will likely to
be accessed as well. Thus having all that in colocated cacheline would
actually be useful.
2) Convert enabling/lock status from bitfield to bool or accessed via bitmasks.
I am agreeing to feedback here and will do that once we converge on point 1.
>+
>+#endif /* CONFIG_RISCV_USER_CFI */
>+
>+#endif /* __ASSEMBLY__ */
>+
>+#endif /* _ASM_RISCV_USERCFI_H */
>diff --git a/arch/riscv/kernel/asm-offsets.c b/arch/riscv/kernel/asm-offsets.c
>index e89455a6a0e5..0c188aaf3925 100644
>--- a/arch/riscv/kernel/asm-offsets.c
>+++ b/arch/riscv/kernel/asm-offsets.c
>@@ -50,6 +50,10 @@ void asm_offsets(void)
> #endif
>
> OFFSET(TASK_TI_CPU_NUM, task_struct, thread_info.cpu);
>+#ifdef CONFIG_RISCV_USER_CFI
>+ OFFSET(TASK_TI_CFI_STATUS, task_struct, thread_info.user_cfi_state);
>+ OFFSET(TASK_TI_USER_SSP, task_struct, thread_info.user_cfi_state.user_shdw_stk);
>+#endif
> OFFSET(TASK_THREAD_F0, task_struct, thread.fstate.f[0]);
> OFFSET(TASK_THREAD_F1, task_struct, thread.fstate.f[1]);
> OFFSET(TASK_THREAD_F2, task_struct, thread.fstate.f[2]);
>diff --git a/arch/riscv/kernel/entry.S b/arch/riscv/kernel/entry.S
>index 33a5a9f2a0d4..f5531d82f7e7 100644
>--- a/arch/riscv/kernel/entry.S
>+++ b/arch/riscv/kernel/entry.S
>@@ -147,6 +147,20 @@ SYM_CODE_START(handle_exception)
>
> REG_L s0, TASK_TI_USER_SP(tp)
> csrrc s1, CSR_STATUS, t0
>+ /*
>+ * If previous mode was U, capture shadow stack pointer and save it away
>+ * Zero CSR_SSP at the same time for sanitization.
>+ */
>+ ALTERNATIVE("nops(4)",
>+ __stringify( \
>+ andi s2, s1, SR_SPP; \
>+ bnez s2, skip_ssp_save; \
>+ csrrw s2, CSR_SSP, x0; \
>+ REG_S s2, TASK_TI_USER_SSP(tp); \
>+ skip_ssp_save:),
>+ 0,
>+ RISCV_ISA_EXT_ZICFISS,
>+ CONFIG_RISCV_USER_CFI)
> csrr s2, CSR_EPC
> csrr s3, CSR_TVAL
> csrr s4, CSR_CAUSE
>@@ -236,6 +250,15 @@ SYM_CODE_START_NOALIGN(ret_from_exception)
> * structures again.
> */
> csrw CSR_SCRATCH, tp
>+
>+ ALTERNATIVE("nops(2)",
>+ __stringify( \
>+ REG_L s3, TASK_TI_USER_SSP(tp); \
>+ csrw CSR_SSP, s3),
>+ 0,
>+ RISCV_ISA_EXT_ZICFISS,
>+ CONFIG_RISCV_USER_CFI)
>+
> 1:
> #ifdef CONFIG_RISCV_ISA_V_PREEMPTIVE
> move a0, sp
>
>--
>2.43.0
>
Powered by blists - more mailing lists