* [PATCH] riscv: ptrace: reject CFI regset access when extensions are absent
@ 2026-08-20 6:32 Chen Pei
2026-08-20 11:45 ` Guo Ren
0 siblings, 1 reply; 3+ messages in thread
From: Chen Pei @ 2026-08-20 6:32 UTC (permalink / raw)
To: pjw, oleg, debug; +Cc: alex, guoren, linux-riscv, linux-kernel
riscv_cfi_get() and riscv_cfi_set() do not check whether the Zicfilp
or Zicfiss extensions are present. On systems without them,
PTRACE_GETREGSET on REGSET_CFI still succeeds and returns a zeroed
user_cfi_state, misleading debuggers into believing the register set
is available, and PTRACE_SETREGSET silently accepts writes that have
no effect (e.g. clearing SR_ELP).
Reject the access with -EINVAL when neither branch landing pads nor
shadow stack is available to userspace, using the same availability
helpers as the prctl path.
Fixes: 2af7c9cf021c ("riscv/ptrace: expose riscv CFI status and state via ptrace and in core files")
Signed-off-by: Chen Pei <cp0613@linux.alibaba.com>
---
This follows the behaviour of the arm64 GCS regset. Unlike vector
registers, no ENODATA case applies here: the CFI status regset has a
valid all-zero representation even when CFI has not been enabled for
the traced task.
is_user_lpad_enabled()/is_user_shstk_enabled() are used instead of a
plain ISA check so that the regset visibility matches what userspace
can actually use via prctl: both helpers also honor the
riscv_nousercfi kernel command line switch.
arch/riscv/kernel/ptrace.c | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/arch/riscv/kernel/ptrace.c b/arch/riscv/kernel/ptrace.c
index f336a183667e..566856e42f65 100644
--- a/arch/riscv/kernel/ptrace.c
+++ b/arch/riscv/kernel/ptrace.c
@@ -299,6 +299,9 @@ static int riscv_cfi_get(struct task_struct *target,
struct user_cfi_state user_cfi;
struct pt_regs *regs;
+ if (!is_user_lpad_enabled() && !is_user_shstk_enabled())
+ return -EINVAL;
+
memset(&user_cfi, 0, sizeof(user_cfi));
regs = task_pt_regs(target);
@@ -337,6 +340,9 @@ static int riscv_cfi_set(struct task_struct *target,
struct user_cfi_state user_cfi;
struct pt_regs *regs;
+ if (!is_user_lpad_enabled() && !is_user_shstk_enabled())
+ return -EINVAL;
+
regs = task_pt_regs(target);
ret = user_regset_copyin(&pos, &count, &kbuf, &ubuf, &user_cfi, 0, -1);
--
2.50.1
_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv
^ permalink raw reply related [flat|nested] 3+ messages in thread* Re: [PATCH] riscv: ptrace: reject CFI regset access when extensions are absent
2026-08-20 6:32 [PATCH] riscv: ptrace: reject CFI regset access when extensions are absent Chen Pei
@ 2026-08-20 11:45 ` Guo Ren
2026-08-20 12:26 ` Chen Pei
0 siblings, 1 reply; 3+ messages in thread
From: Guo Ren @ 2026-08-20 11:45 UTC (permalink / raw)
To: Chen Pei; +Cc: pjw, oleg, debug, alex, linux-riscv, linux-kernel
On Thu, Aug 20, 2026 at 2:32 PM Chen Pei <cp0613@linux.alibaba.com> wrote:
>
> riscv_cfi_get() and riscv_cfi_set() do not check whether the Zicfilp
> or Zicfiss extensions are present. On systems without them,
> PTRACE_GETREGSET on REGSET_CFI still succeeds and returns a zeroed
> user_cfi_state, misleading debuggers into believing the register set
> is available, and PTRACE_SETREGSET silently accepts writes that have
> no effect (e.g. clearing SR_ELP).
>
> Reject the access with -EINVAL when neither branch landing pads nor
> shadow stack is available to userspace, using the same availability
> helpers as the prctl path.
>
> Fixes: 2af7c9cf021c ("riscv/ptrace: expose riscv CFI status and state via ptrace and in core files")
Cc: stable@vger.kernel.org
> Signed-off-by: Chen Pei <cp0613@linux.alibaba.com>
> ---
> This follows the behaviour of the arm64 GCS regset. Unlike vector
> registers, no ENODATA case applies here: the CFI status regset has a
> valid all-zero representation even when CFI has not been enabled for
> the traced task.
>
> is_user_lpad_enabled()/is_user_shstk_enabled() are used instead of a
> plain ISA check so that the regset visibility matches what userspace
> can actually use via prctl: both helpers also honor the
> riscv_nousercfi kernel command line switch.
>
> arch/riscv/kernel/ptrace.c | 6 ++++++
> 1 file changed, 6 insertions(+)
>
> diff --git a/arch/riscv/kernel/ptrace.c b/arch/riscv/kernel/ptrace.c
> index f336a183667e..566856e42f65 100644
> --- a/arch/riscv/kernel/ptrace.c
> +++ b/arch/riscv/kernel/ptrace.c
> @@ -299,6 +299,9 @@ static int riscv_cfi_get(struct task_struct *target,
> struct user_cfi_state user_cfi;
> struct pt_regs *regs;
>
> + if (!is_user_lpad_enabled() && !is_user_shstk_enabled())
Do you want:
/* If shadow stack is not supported or not enabled, nothing to ... */
if (!is_user_shstk_enabled() || !is_shstk_enabled(tsk))
> + return -EINVAL;
> +
> memset(&user_cfi, 0, sizeof(user_cfi));
> regs = task_pt_regs(target);
>
> @@ -337,6 +340,9 @@ static int riscv_cfi_set(struct task_struct *target,
> struct user_cfi_state user_cfi;
> struct pt_regs *regs;
>
> + if (!is_user_lpad_enabled() && !is_user_shstk_enabled())
> + return -EINVAL;
> +
> regs = task_pt_regs(target);
>
> ret = user_regset_copyin(&pos, &count, &kbuf, &ubuf, &user_cfi, 0, -1);
> --
> 2.50.1
>
--
Best Regards
Guo Ren
_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv
^ permalink raw reply [flat|nested] 3+ messages in thread* Re: [PATCH] riscv: ptrace: reject CFI regset access when extensions are absent
2026-08-20 11:45 ` Guo Ren
@ 2026-08-20 12:26 ` Chen Pei
0 siblings, 0 replies; 3+ messages in thread
From: Chen Pei @ 2026-08-20 12:26 UTC (permalink / raw)
To: Guo Ren
Cc: Paul Walmsley, Palmer Dabbelt, Albert Ou, Oleg Nesterov,
Deepak Gupta, Alexandre Ghiti, linux-riscv, linux-kernel
Hi Guo Ren,
Thanks for the review.
On 2026/8/20 19:45, Guo Ren wrote:
> On Thu, Aug 20, 2026 at 2:32 PM Chen Pei <cp0613@linux.alibaba.com> wrote:
>> + if (!is_user_lpad_enabled() && !is_user_shstk_enabled())
> Do you want:
>
> /* If shadow stack is not supported or not enabled, nothing to ... */
> if (!is_user_shstk_enabled() || !is_shstk_enabled(tsk))
There are two separate points here, let me clarify both.
First, on "&&" vs "||" between the two features: the combined check is
intentional. Zicfilp and Zicfiss are independent extensions and the
kernel treats them as such everywhere (separate hwprobe keys, separate
prctls, separate riscv_nousercfi switches). Rejecting the regset as
soon as either one is missing would also take away the useful part: on
a system with only shadow stack, shstk_ptr is exactly what a debugger
needs for shadow stack unwinding, and symmetrically for landing pads.
With "&&", the regset stays available when at least one feature is
present, and the missing feature's section reads as all-zero, which is
accurate: its per-task enable flags can only be set when the feature
is available, since the prctl paths are gated by
is_user_lpad_enabled()/is_user_shstk_enabled() individually. The same
applies to riscv_cfi_set(): a "||" would wrongly block legitimate
shstk_ptr updates on shadow-stack-only systems.
Second, on the per-task check (is_shstk_enabled(target) and friends):
I would prefer not to reject the access when CFI is simply not enabled
on the traced task. The all-zero state is a meaningful answer -- it
tells the debugger that CFI is not enabled for this task. This matches
the arm64 GCS regset, which only checks system support in gcs_get()
and returns the task's (possibly zero) state unconditionally.
Best regards,
Pei
_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2026-08-20 12:27 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2026-08-20 6:32 [PATCH] riscv: ptrace: reject CFI regset access when extensions are absent Chen Pei
2026-08-20 11:45 ` Guo Ren
2026-08-20 12:26 ` Chen Pei
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox