From: Zong Li <zong.li@sifive.com>
To: Deepak Gupta <debug@rivosinc.com>
Cc: "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>,
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
Subject: Re: [PATCH v17 15/27] riscv/traps: Introduce software check exception and uprobe handling
Date: Mon, 16 Jun 2025 15:31:31 +0800 [thread overview]
Message-ID: <CANXhq0pRXX_OMW2g2ui-k7Z_ZT+5a8Sra8oE28nBh5B9K2L5bQ@mail.gmail.com> (raw)
In-Reply-To: <20250604-v5_user_cfi_series-v17-15-4565c2cf869f@rivosinc.com>
On Thu, Jun 5, 2025 at 1:17 AM Deepak Gupta <debug@rivosinc.com> wrote:
>
> zicfiss / zicfilp introduces a new exception to priv isa `software check
> exception` with cause code = 18. This patch implements software check
> exception.
>
> Additionally it implements a cfi violation handler which checks for code
> in xtval. If xtval=2, it means that sw check exception happened because of
> an indirect branch not landing on 4 byte aligned PC or not landing on
> `lpad` instruction or label value embedded in `lpad` not matching label
> value setup in `x7`. If xtval=3, it means that sw check exception happened
> because of mismatch between link register (x1 or x5) and top of shadow
> stack (on execution of `sspopchk`).
>
> In case of cfi violation, SIGSEGV is raised with code=SEGV_CPERR.
> SEGV_CPERR was introduced by x86 shadow stack patches.
>
> To keep uprobes working, handle the uprobe event first before reporting
> the CFI violation in software-check exception handler. Because when the
> landing pad is activated, if the uprobe point is set at the lpad
> instruction at the beginning of a function, the system triggers a software
> -check exception instead of an ebreak exception due to the exception
> priority, then uprobe can't work successfully.
>
> Co-developed-by: Zong Li <zong.li@sifive.com>
> Reviewed-by: Zong Li <zong.li@sifive.com>
> Signed-off-by: Zong Li <zong.li@sifive.com>
> Signed-off-by: Deepak Gupta <debug@rivosinc.com>
> ---
> arch/riscv/include/asm/asm-prototypes.h | 1 +
> arch/riscv/include/asm/entry-common.h | 2 ++
> arch/riscv/kernel/entry.S | 3 ++
> arch/riscv/kernel/traps.c | 51 +++++++++++++++++++++++++++++++++
> 4 files changed, 57 insertions(+)
>
> diff --git a/arch/riscv/include/asm/asm-prototypes.h b/arch/riscv/include/asm/asm-prototypes.h
> index cd627ec289f1..5a27cefd7805 100644
> --- a/arch/riscv/include/asm/asm-prototypes.h
> +++ b/arch/riscv/include/asm/asm-prototypes.h
> @@ -51,6 +51,7 @@ DECLARE_DO_ERROR_INFO(do_trap_ecall_u);
> DECLARE_DO_ERROR_INFO(do_trap_ecall_s);
> DECLARE_DO_ERROR_INFO(do_trap_ecall_m);
> DECLARE_DO_ERROR_INFO(do_trap_break);
> +DECLARE_DO_ERROR_INFO(do_trap_software_check);
>
> asmlinkage void handle_bad_stack(struct pt_regs *regs);
> asmlinkage void do_page_fault(struct pt_regs *regs);
> diff --git a/arch/riscv/include/asm/entry-common.h b/arch/riscv/include/asm/entry-common.h
> index b28ccc6cdeea..34ed149af5d1 100644
> --- a/arch/riscv/include/asm/entry-common.h
> +++ b/arch/riscv/include/asm/entry-common.h
> @@ -40,4 +40,6 @@ static inline int handle_misaligned_store(struct pt_regs *regs)
> }
> #endif
>
> +bool handle_user_cfi_violation(struct pt_regs *regs);
> +
> #endif /* _ASM_RISCV_ENTRY_COMMON_H */
> diff --git a/arch/riscv/kernel/entry.S b/arch/riscv/kernel/entry.S
> index 978115567bca..8d25837a9384 100644
> --- a/arch/riscv/kernel/entry.S
> +++ b/arch/riscv/kernel/entry.S
> @@ -474,6 +474,9 @@ SYM_DATA_START_LOCAL(excp_vect_table)
> RISCV_PTR do_page_fault /* load page fault */
> RISCV_PTR do_trap_unknown
> RISCV_PTR do_page_fault /* store page fault */
> + RISCV_PTR do_trap_unknown /* cause=16 */
> + RISCV_PTR do_trap_unknown /* cause=17 */
> + RISCV_PTR do_trap_software_check /* cause=18 is sw check exception */
> SYM_DATA_END_LABEL(excp_vect_table, SYM_L_LOCAL, excp_vect_table_end)
>
> #ifndef CONFIG_MMU
> diff --git a/arch/riscv/kernel/traps.c b/arch/riscv/kernel/traps.c
> index 8ff8e8b36524..64388370e1ad 100644
> --- a/arch/riscv/kernel/traps.c
> +++ b/arch/riscv/kernel/traps.c
> @@ -354,6 +354,57 @@ void do_trap_ecall_u(struct pt_regs *regs)
>
> }
>
> +#define CFI_TVAL_FCFI_CODE 2
> +#define CFI_TVAL_BCFI_CODE 3
> +/* handle cfi violations */
> +bool handle_user_cfi_violation(struct pt_regs *regs)
> +{
> + unsigned long tval = csr_read(CSR_TVAL);
> + bool is_fcfi = (tval == CFI_TVAL_FCFI_CODE && cpu_supports_indirect_br_lp_instr());
> + bool is_bcfi = (tval == CFI_TVAL_BCFI_CODE && cpu_supports_shadow_stack());
> +
> + /*
> + * Handle uprobe event first. The probe point can be a valid target
> + * of indirect jumps or calls, in this case, forward cfi violation
> + * will be triggered instead of breakpoint exception.
> + */
> + if (is_fcfi && probe_breakpoint_handler(regs))
> + return true;
Hi Deepak,
Sorry for missing something earlier. I think we would like to clear
sstatus.SPELP in the uprobe handling case. For example:
diff --git a/arch/riscv/kernel/traps.c b/arch/riscv/kernel/traps.c
index c2ea999c1167..e8492bb57e09 100644
--- a/arch/riscv/kernel/traps.c
+++ b/arch/riscv/kernel/traps.c
@@ -349,8 +349,10 @@ bool handle_user_cfi_violation(struct pt_regs *regs)
bool is_fcfi = (tval == CFI_TVAL_FCFI_CODE &&
cpu_supports_indirect_br_lp_instr());
bool is_bcfi = (tval == CFI_TVAL_BCFI_CODE &&
cpu_supports_shadow_stack());
- if (is_fcfi && probe_breakpoint_handler(regs))
+ if (is_fcfi && probe_breakpoint_handler(regs)) {
+ regs->status = regs->status & ~SR_ELP;
return true;
+ }
if (is_fcfi || is_bcfi) {
do_trap_error(regs, SIGSEGV, SEGV_CPERR, regs->epc,
When a user mode CFI violation occurs, the ELP state should be 1, and
the system traps into supervisor mode. During this trap, sstatus.SPELP
is set to 1, and the ELP state is reset to 0. If we don’t clear
sstatus.SPELP, the ELP state will become 1 again after executing the
sret instruction. As a result, the system might trigger another
forward CFI violation upon executing the next instruction in the user
program, unless it happens to be a lpad instruction.
The previous patch was tested on QEMU, but QEMU does not set the
sstatus.SPELP bit to 1 when a forward CFI violation occurs. Therefore,
I suspect that QEMU might also require some fixes.
Thanks
> +
> + if (is_fcfi || is_bcfi) {
> + do_trap_error(regs, SIGSEGV, SEGV_CPERR, regs->epc,
> + "Oops - control flow violation");
> + return true;
> + }
> +
> + return false;
> +}
> +
> +/*
> + * software check exception is defined with risc-v cfi spec. Software check
> + * exception is raised when:-
> + * a) An indirect branch doesn't land on 4 byte aligned PC or `lpad`
> + * instruction or `label` value programmed in `lpad` instr doesn't
> + * match with value setup in `x7`. reported code in `xtval` is 2.
> + * b) `sspopchk` instruction finds a mismatch between top of shadow stack (ssp)
> + * and x1/x5. reported code in `xtval` is 3.
> + */
> +asmlinkage __visible __trap_section void do_trap_software_check(struct pt_regs *regs)
> +{
> + if (user_mode(regs)) {
> + irqentry_enter_from_user_mode(regs);
> +
> + /* not a cfi violation, then merge into flow of unknown trap handler */
> + if (!handle_user_cfi_violation(regs))
> + do_trap_unknown(regs);
> +
> + irqentry_exit_to_user_mode(regs);
> + } else {
> + /* sw check exception coming from kernel is a bug in kernel */
> + die(regs, "Kernel BUG");
> + }
> +}
> +
> #ifdef CONFIG_MMU
> asmlinkage __visible noinstr void do_page_fault(struct pt_regs *regs)
> {
>
> --
> 2.43.0
>
next prev parent reply other threads:[~2025-06-16 7:31 UTC|newest]
Thread overview: 35+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-06-04 17:15 [PATCH v17 00/27] riscv control-flow integrity for usermode Deepak Gupta
2025-06-04 17:15 ` [PATCH v17 01/27] mm: VM_SHADOW_STACK definition for riscv Deepak Gupta
2025-06-04 17:15 ` [PATCH v17 02/27] dt-bindings: riscv: zicfilp and zicfiss in dt-bindings (extensions.yaml) Deepak Gupta
2025-06-04 17:15 ` [PATCH v17 03/27] riscv: zicfiss / zicfilp enumeration Deepak Gupta
2025-06-04 17:15 ` [PATCH v17 04/27] riscv: zicfiss / zicfilp extension csr and bit definitions Deepak Gupta
2025-06-04 17:15 ` [PATCH v17 05/27] riscv: usercfi state for task and save/restore of CSR_SSP on trap entry/exit Deepak Gupta
2025-06-04 17:15 ` [PATCH v17 06/27] riscv/mm : ensure PROT_WRITE leads to VM_READ | VM_WRITE Deepak Gupta
2025-06-04 17:15 ` [PATCH v17 07/27] riscv/mm: manufacture shadow stack pte Deepak Gupta
2025-06-04 17:15 ` [PATCH v17 08/27] riscv/mm: teach pte_mkwrite to manufacture shadow stack PTEs Deepak Gupta
2025-06-04 17:15 ` [PATCH v17 09/27] riscv/mm: write protect and shadow stack Deepak Gupta
2025-06-04 17:15 ` [PATCH v17 10/27] riscv/mm: Implement map_shadow_stack() syscall Deepak Gupta
2025-06-04 17:15 ` [PATCH v17 11/27] riscv/shstk: If needed allocate a new shadow stack on clone Deepak Gupta
2025-06-04 17:15 ` [PATCH v17 12/27] riscv: Implements arch agnostic shadow stack prctls Deepak Gupta
2025-06-04 17:15 ` [PATCH v17 13/27] prctl: arch-agnostic prctl for indirect branch tracking Deepak Gupta
2025-06-04 17:15 ` [PATCH v17 14/27] riscv: Implements arch agnostic indirect branch tracking prctls Deepak Gupta
2025-06-04 17:15 ` [PATCH v17 15/27] riscv/traps: Introduce software check exception and uprobe handling Deepak Gupta
2025-06-16 7:31 ` Zong Li [this message]
2025-06-20 2:16 ` Zong Li
2025-06-20 17:33 ` Deepak Gupta
2025-07-15 21:33 ` Deepak Gupta
2025-07-16 2:06 ` Zong Li
2025-07-16 7:33 ` Deepak Gupta
2025-06-04 17:15 ` [PATCH v17 16/27] riscv: signal: abstract header saving for setup_sigcontext Deepak Gupta
2025-06-04 17:15 ` [PATCH v17 17/27] riscv/signal: save and restore of shadow stack for signal Deepak Gupta
2025-06-04 17:15 ` [PATCH v17 18/27] riscv/kernel: update __show_regs to print shadow stack register Deepak Gupta
2025-06-04 17:15 ` [PATCH v17 19/27] riscv/ptrace: riscv cfi status and state via ptrace and in core files Deepak Gupta
2025-06-04 17:15 ` [PATCH v17 20/27] riscv/hwprobe: zicfilp / zicfiss enumeration in hwprobe Deepak Gupta
2025-06-04 17:15 ` [PATCH v17 21/27] riscv: kernel command line option to opt out of user cfi Deepak Gupta
2025-06-04 17:15 ` [PATCH v17 22/27] riscv: enable kernel access to shadow stack memory via FWFT sbi call Deepak Gupta
2025-06-04 17:15 ` [PATCH v17 23/27] arch/riscv: compile vdso with landing pad Deepak Gupta
2025-06-24 7:29 ` Zong Li
2025-06-04 17:15 ` [PATCH v17 24/27] riscv: create a config for shadow stack and landing pad instr support Deepak Gupta
2025-06-04 17:15 ` [PATCH v17 25/27] riscv: Documentation for landing pad / indirect branch tracking Deepak Gupta
2025-06-04 17:15 ` [PATCH v17 26/27] riscv: Documentation for shadow stack on riscv Deepak Gupta
2025-06-04 17:15 ` [PATCH v17 27/27] kselftest/riscv: kselftest for user mode cfi 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=CANXhq0pRXX_OMW2g2ui-k7Z_ZT+5a8Sra8oE28nBh5B9K2L5bQ@mail.gmail.com \
--to=zong.li@sifive.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=debug@rivosinc.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 \
/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).