mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Deepak Gupta <debug@rivosinc.com>
To: Jesse Taube <jesse@rivosinc.com>
Cc: linux-riscv@lists.infradead.org, linux-kernel@vger.kernel.org,
	"Paul Walmsley" <paul.walmsley@sifive.com>,
	"Palmer Dabbelt" <palmer@dabbelt.com>,
	"Albert Ou" <aou@eecs.berkeley.edu>,
	"Alexandre Ghiti" <alex@ghiti.fr>,
	"Oleg Nesterov" <oleg@redhat.com>,
	"Himanshu Chauhan" <hchauhan@ventanamicro.com>,
	"Charlie Jenkins" <charlie@rivosinc.com>,
	"Samuel Holland" <samuel.holland@sifive.com>,
	"Andrew Jones" <ajones@ventanamicro.com>,
	"Atish Patra" <atishp@rivosinc.com>,
	"Anup Patel" <apatel@ventanamicro.com>,
	"Mayuresh Chitale" <mchitale@ventanamicro.com>,
	"Conor Dooley" <conor.dooley@microchip.com>,
	WangYuli <wangyuli@uniontech.com>,
	"Huacai Chen" <chenhuacai@kernel.org>,
	"Nam Cao" <namcao@linutronix.de>,
	"Andrew Morton" <akpm@linux-foundation.org>,
	"Mike Rapoport (Microsoft)" <rppt@kernel.org>,
	"Luis Chamberlain" <mcgrof@kernel.org>,
	"Yunhui Cui" <cuiyunhui@bytedance.com>,
	"Joel Granados" <joel.granados@kernel.org>,
	"Clément Léger" <cleger@rivosinc.com>,
	"Celeste Liu" <coelacanthushex@gmail.com>,
	"Evan Green" <evan@rivosinc.com>,
	"Nylon Chen" <nylon.chen@sifive.com>
Subject: Re: [RFC PATCH 6/6] riscv: ptrace: Add hw breakpoint support
Date: Tue, 22 Jul 2025 21:18:23 -0700	[thread overview]
Message-ID: <aIBij4hr3Jna8OjV@debug.ba.rivosinc.com> (raw)
In-Reply-To: <20250722173829.984082-7-jesse@rivosinc.com>

On Tue, Jul 22, 2025 at 10:38:29AM -0700, Jesse Taube wrote:
>Add ability to setup hw breakpoints to ptrace. Call defines a new
>structure of (ulong[3]){bp_addr, bp_len, bp_type} with
>bp_type being one of HW_BREAKPOINT_LEN_X and
>bp_len being one of HW_BREAKPOINT_X with a value of
>zero dissabling the breakpoint.
>
>Signed-off-by: Jesse Taube <jesse@rivosinc.com>
>---
> arch/riscv/include/asm/processor.h   |  4 ++
> arch/riscv/include/uapi/asm/ptrace.h |  3 +-
> arch/riscv/kernel/hw_breakpoint.c    | 14 ++++-
> arch/riscv/kernel/process.c          |  4 ++
> arch/riscv/kernel/ptrace.c           | 93 ++++++++++++++++++++++++++++
> 5 files changed, 116 insertions(+), 2 deletions(-)
>
>diff --git a/arch/riscv/include/asm/processor.h b/arch/riscv/include/asm/processor.h
>index 5f56eb9d114a..488d956a951f 100644
>--- a/arch/riscv/include/asm/processor.h
>+++ b/arch/riscv/include/asm/processor.h
>@@ -12,6 +12,7 @@
>
> #include <vdso/processor.h>
>
>+#include <asm/hw_breakpoint.h>
> #include <asm/ptrace.h>
>
> #define arch_get_mmap_end(addr, len, flags)			\
>@@ -108,6 +109,9 @@ struct thread_struct {
> 	struct __riscv_v_ext_state vstate;
> 	unsigned long align_ctl;
> 	struct __riscv_v_ext_state kernel_vstate;
>+#ifdef CONFIG_HAVE_HW_BREAKPOINT
>+	struct perf_event *ptrace_bps[RV_MAX_TRIGGERS];
>+#endif
> #ifdef CONFIG_SMP
> 	/* Flush the icache on migration */
> 	bool force_icache_flush;
>diff --git a/arch/riscv/include/uapi/asm/ptrace.h b/arch/riscv/include/uapi/asm/ptrace.h
>index a38268b19c3d..a7998ed41913 100644
>--- a/arch/riscv/include/uapi/asm/ptrace.h
>+++ b/arch/riscv/include/uapi/asm/ptrace.h
>@@ -14,7 +14,8 @@
>
> #define PTRACE_GETFDPIC_EXEC	0
> #define PTRACE_GETFDPIC_INTERP	1
>-
>+#define PTRACE_GETHBPREGS	2
>+#define PTRACE_SETHBPREGS	3

Why not use `PTRACE_GETREGSET` `PTRACE_SETREGSET` ?

> /*
>  * User-mode register state for core dumps, ptrace, sigcontext
>  *
>diff --git a/arch/riscv/kernel/hw_breakpoint.c b/arch/riscv/kernel/hw_breakpoint.c
>index 437fd82b9590..c58145464539 100644
>--- a/arch/riscv/kernel/hw_breakpoint.c
>+++ b/arch/riscv/kernel/hw_breakpoint.c
>@@ -633,7 +633,19 @@ void arch_uninstall_hw_breakpoint(struct perf_event *event)
> 		pr_warn("%s: Failed to uninstall trigger %d. error: %ld\n", __func__, i, ret.error);
> }
>
>-void flush_ptrace_hw_breakpoint(struct task_struct *tsk) { }
>+/*
>+ * Release the user breakpoints used by ptrace
>+ */
>+void flush_ptrace_hw_breakpoint(struct task_struct *tsk)
>+{
>+	int i;
>+	struct thread_struct *t = &tsk->thread;
>+
>+	for (i = 0; i < dbtr_total_num; i++) {
>+		unregister_hw_breakpoint(t->ptrace_bps[i]);
>+		t->ptrace_bps[i] = NULL;
>+	}
>+}
>
> void hw_breakpoint_pmu_read(struct perf_event *bp) { }
>
>diff --git a/arch/riscv/kernel/process.c b/arch/riscv/kernel/process.c
>index 15d8f75902f8..9cf07ecfb523 100644
>--- a/arch/riscv/kernel/process.c
>+++ b/arch/riscv/kernel/process.c
>@@ -9,6 +9,7 @@
>
> #include <linux/bitfield.h>
> #include <linux/cpu.h>
>+#include <linux/hw_breakpoint.h>
> #include <linux/kernel.h>
> #include <linux/sched.h>
> #include <linux/sched/debug.h>
>@@ -164,6 +165,7 @@ void start_thread(struct pt_regs *regs, unsigned long pc,
>
> void flush_thread(void)
> {
>+	flush_ptrace_hw_breakpoint(current);
> #ifdef CONFIG_FPU
> 	/*
> 	 * Reset FPU state and context
>@@ -218,6 +220,8 @@ int copy_thread(struct task_struct *p, const struct kernel_clone_args *args)
> 		set_bit(MM_CONTEXT_LOCK_PMLEN, &p->mm->context.flags);
>
> 	memset(&p->thread.s, 0, sizeof(p->thread.s));
>+	if (IS_ENABLED(CONFIG_HAVE_HW_BREAKPOINT))
>+		memset(p->thread.ptrace_bps, 0, sizeof(p->thread.ptrace_bps));
>
> 	/* p->thread holds context to be restored by __switch_to() */
> 	if (unlikely(args->fn)) {
>diff --git a/arch/riscv/kernel/ptrace.c b/arch/riscv/kernel/ptrace.c
>index ea67e9fb7a58..b78cfb0f1c0e 100644
>--- a/arch/riscv/kernel/ptrace.c
>+++ b/arch/riscv/kernel/ptrace.c
>@@ -9,11 +9,13 @@
>
> #include <asm/vector.h>
> #include <asm/ptrace.h>
>+#include <asm/hw_breakpoint.h>
> #include <asm/syscall.h>
> #include <asm/thread_info.h>
> #include <asm/switch_to.h>
> #include <linux/audit.h>
> #include <linux/compat.h>
>+#include <linux/hw_breakpoint.h>
> #include <linux/ptrace.h>
> #include <linux/elf.h>
> #include <linux/regset.h>
>@@ -336,12 +338,103 @@ void ptrace_disable(struct task_struct *child)
> {
> }
>
>+#ifdef CONFIG_HAVE_HW_BREAKPOINT
>+static void ptrace_hbptriggered(struct perf_event *bp,
>+				struct perf_sample_data *data,
>+				struct pt_regs *regs)
>+{
>+	struct arch_hw_breakpoint *bkpt = counter_arch_bp(bp);
>+	int num = 0;
>+
>+	force_sig_ptrace_errno_trap(num, (void __user *)bkpt->address);
>+}
>+
>+/*
>+ * idx selects the breakpoint index.
>+ * Both PTRACE_GETHBPREGS and PTRACE_SETHBPREGS transfer three 32-bit words:
>+ * address (0), length (1), type (2).
>+ * Instruction breakpoint length is one of HW_BREAKPOINT_LEN_X or 0. 0 will
>+ * disable the breakpoint.
>+ * Instruction breakpoint type is one of HW_BREAKPOINT_X.
>+ */
>+
>+static long ptrace_gethbpregs(struct task_struct *child, unsigned long idx,
>+			      unsigned long __user *datap)
>+{
>+	struct perf_event *bp;
>+	unsigned long user_data[3] = {0};
>+
>+	if (idx >= RV_MAX_TRIGGERS)
>+		return -EINVAL;
>+
>+	bp = child->thread.ptrace_bps[idx];
>+
>+	if (!IS_ERR_OR_NULL(bp)) {
>+		user_data[0] = bp->attr.bp_addr;
>+		user_data[1] = bp->attr.disabled ? 0 : bp->attr.bp_len;
>+		user_data[2] = bp->attr.bp_type;
>+	}
>+
>+	if (copy_to_user(datap, user_data, sizeof(user_data)))
>+		return -EFAULT;
>+
>+	return 0;
>+}
>+
>+static long ptrace_sethbpregs(struct task_struct *child, unsigned long idx,
>+			      unsigned long __user *datap)
>+{
>+	struct perf_event *bp;
>+	struct perf_event_attr attr;
>+	unsigned long user_data[3];
>+
>+	if (idx >= RV_MAX_TRIGGERS)
>+		return -EINVAL;
>+
>+	if (copy_from_user(user_data, datap, sizeof(user_data)))
>+		return -EFAULT;
>+
>+	bp = child->thread.ptrace_bps[idx];
>+	if (IS_ERR_OR_NULL(bp))

Why not only check for NULL?
IS_ERR_VALUE will always expand to be true. right?

>+		attr = bp->attr;
>+	else
>+		ptrace_breakpoint_init(&attr);
>+
>+	attr.bp_addr = user_data[0];
>+	attr.bp_len = user_data[1];
>+	attr.bp_type = user_data[2];
>+	attr.disabled = !attr.bp_len;

Is it okay to not have any sanitization on inputs?

Can these inputs be controlled by user to give kernel address and kernel
breakpoint?

>+
>+	if (IS_ERR_OR_NULL(bp)) {
>+		bp = register_user_hw_breakpoint(&attr, ptrace_hbptriggered, NULL,
>+					   child);
>+		if (IS_ERR(bp))
>+			return PTR_ERR(bp);
>+
>+		child->thread.ptrace_bps[idx] = bp;
>+		return 0;
>+	} else {
>+		return modify_user_hw_breakpoint(bp, &attr);
>+	}
>+}
>+#endif
>+
> long arch_ptrace(struct task_struct *child, long request,
> 		 unsigned long addr, unsigned long data)
> {
> 	long ret = -EIO;
>+	unsigned long __user *datap = (unsigned long __user *) data;
>
> 	switch (request) {
>+#ifdef CONFIG_HAVE_HW_BREAKPOINT
>+	case PTRACE_GETHBPREGS:
>+		ret = ptrace_gethbpregs(child, addr, datap);
>+		break;
>+
>+	case PTRACE_SETHBPREGS:
>+		ret = ptrace_sethbpregs(child, addr, datap);
>+		break;
>+#endif
> 	default:
> 		ret = ptrace_request(child, request, addr, data);
> 		break;
>-- 
>2.43.0
>

  reply	other threads:[~2025-07-23  4:18 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-07-22 17:38 [RFC PATCH 0/6] riscv: add initial support for hardware breakpoints Jesse Taube
2025-07-22 17:38 ` [RFC PATCH 1/6] riscv: Add insn.c, consolidate instruction decoding Jesse Taube
2025-07-22 17:38 ` [RFC PATCH 2/6] riscv: Add SBI debug trigger extension and function ids Jesse Taube
2025-07-22 17:38 ` [RFC PATCH 3/6] riscv: insn: __read_insn use copy_from_X_nofault Jesse Taube
2025-08-04  7:44   ` Clément Léger
2025-07-22 17:38 ` [RFC PATCH 4/6] riscv: Introduce support for hardware break/watchpoints Jesse Taube
2025-07-23  2:49   ` Deepak Gupta
2025-07-23 17:02     ` Jesse Taube
2025-07-23 17:25       ` Deepak Gupta
2025-08-04  8:01   ` Clément Léger
2025-08-04 15:03     ` Jesse Taube
2025-07-22 17:38 ` [RFC PATCH 5/6] riscv: hw_breakpoint: Use icount for single stepping Jesse Taube
2025-08-04  8:15   ` Clément Léger
2025-07-22 17:38 ` [RFC PATCH 6/6] riscv: ptrace: Add hw breakpoint support Jesse Taube
2025-07-23  4:18   ` Deepak Gupta [this message]
2025-07-23 16:55     ` Jesse Taube
2025-07-23 17:23       ` Deepak Gupta
2025-08-04  8:16   ` Clément Léger

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=aIBij4hr3Jna8OjV@debug.ba.rivosinc.com \
    --to=debug@rivosinc.com \
    --cc=ajones@ventanamicro.com \
    --cc=akpm@linux-foundation.org \
    --cc=alex@ghiti.fr \
    --cc=aou@eecs.berkeley.edu \
    --cc=apatel@ventanamicro.com \
    --cc=atishp@rivosinc.com \
    --cc=charlie@rivosinc.com \
    --cc=chenhuacai@kernel.org \
    --cc=cleger@rivosinc.com \
    --cc=coelacanthushex@gmail.com \
    --cc=conor.dooley@microchip.com \
    --cc=cuiyunhui@bytedance.com \
    --cc=evan@rivosinc.com \
    --cc=hchauhan@ventanamicro.com \
    --cc=jesse@rivosinc.com \
    --cc=joel.granados@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-riscv@lists.infradead.org \
    --cc=mcgrof@kernel.org \
    --cc=mchitale@ventanamicro.com \
    --cc=namcao@linutronix.de \
    --cc=nylon.chen@sifive.com \
    --cc=oleg@redhat.com \
    --cc=palmer@dabbelt.com \
    --cc=paul.walmsley@sifive.com \
    --cc=rppt@kernel.org \
    --cc=samuel.holland@sifive.com \
    --cc=wangyuli@uniontech.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

all inboxes | Powered by JetHome®