Linux Trace Kernel
 help / color / mirror / Atom feed
From: sashiko-bot@kernel.org
To: "Sahil Siddiq" <sahilcdq0@gmail.com>
Cc: linux-trace-kernel@vger.kernel.org
Subject: Re: [PATCH v2 2/4] openrisc: Add KProbes
Date: Wed, 30 Sep 2026 20:46:04 +0000	[thread overview]
Message-ID: <20260930204605.389441F000FF@smtp.kernel.org> (raw)
In-Reply-To: <20260930203129.51048-3-sahilcdq0@gmail.com>

Thank you for your contribution! Sashiko AI review found 6 potential issue(s) to consider:
- [High] kprobes: unsafe direct memory access in arch_prepare_kprobe()
- [High] kprobes: unsafe direct memory access in kprobe_breakpoint_handler()
- [High] kprobes: SSOL executes with interrupts enabled due to missing regs->sr update
- [High] kprobes: preemption count and lockdep state leak on KPROBE_REENTER
- [Medium] kprobes: missing NOKPROBE_SYMBOL() for simulate_branch() and simulate_pc()
- [Medium] kprobes: l.jalr state corruption on delay slot page fault
--

commit a255007d852431d07365105e6070af0de294b166
Author: Sahil Siddiq <sahilcdq0@gmail.com>

openrisc: Add KProbes
    
Add KProbes support for OpenRISC, based on similar work done for LoongArch,
MIPS and RISC-V. KProbes make it possible to trap at almost any address in the
kernel to collect performance/debugging info.

> diff --git a/arch/openrisc/kernel/kprobes.c b/arch/openrisc/kernel/kprobes.c
> new file mode 100644
> index 0000000000000..3268ffb0d7077
> --- /dev/null
> +++ b/arch/openrisc/kernel/kprobes.c

[ ... ]

> +int arch_prepare_kprobe(struct kprobe *p)
> +{

[ ... ]

> +	if (insns_need_simulation(insn, &exec_delay_slot) && !exec_delay_slot) {
> +		p->ainsn.insn = NULL;
> +	} else {
> +		/*
> +		 * Single step probed instruction or, in case of branch instructions, single
> +		 * step instruction in delay slot.
> +		 */
> +		p->ainsn.insn = get_insn_slot();
> +		if (!p->ainsn.insn)
> +			return -ENOMEM;
> +
> +		if (exec_delay_slot)
> +			patch_insn_write(p->ainsn.insn, *(p->addr + 1));

[Severity: High]
Does this directly dereference p->addr + 1, bypassing the safety provided
by copy_from_kernel_nofault() used earlier in the function? If the delay slot
instruction falls into an unmapped page, couldn't this cause a kernel panic
during probe registration?

> +		else
> +			patch_insn_write(p->ainsn.insn, p->opcode);
> +		patch_insn_write(&p->ainsn.insn[1], KPROBE_SSTEPBP_INSN);
> +	}
> +
> +	return 0;
> +}

[ ... ]

> +static void post_kprobe_handler(struct kprobe *cur, struct kprobe_ctlblk *kcb,
> +				struct pt_regs *regs)
> +{
> +	instruction_pointer_set(regs, kcb->restore_pc);
> +
> +	if (kcb->kprobe_status == KPROBE_REENTER) {
> +		restore_previous_kprobe(kcb);
> +		return;

[Severity: High]
Does this early return skip calling preempt_enable_no_resched()? If a reentrant
kprobe finishes single-stepping, this seems to permanently leak the preemption
count disabled in kprobe_breakpoint_handler(), which could lead to a system
lockup.

> +	}
> +
> +	kcb->kprobe_status = KPROBE_HIT_SSDONE;
> +
> +	if (cur->post_handler)
> +		cur->post_handler(cur, regs, 0);
> +
> +	reset_current_kprobe();
> +	preempt_enable_no_resched();
> +}

[ ... ]

> +static void setup_singlestep(struct kprobe *p, struct pt_regs *regs,
> +			     struct kprobe_ctlblk *kcb, int reenter)
> +{
> +	kprobe_opcode_t insn;
> +
> +	if (reenter) {
> +		save_previous_kprobe(kcb);
> +		set_current_kprobe(p);
> +		kcb->kprobe_status = KPROBE_REENTER;
> +	} else {
> +		kcb->kprobe_status = KPROBE_HIT_SS;
> +	}
> +
> +	/* Emulate instruction if required. */
> +	insn = p->opcode;
> +	if (is_branch_insn(insn)) {
> +		simulate_branch(regs, insn);

[Severity: Medium]
Since simulate_branch() and simulate_pc() are executed during Kprobe handling,
should they be marked with NOKPROBE_SYMBOL() in arch/openrisc/kernel/insn.c?
Without it, placing a kprobe on these functions and hitting another branch-related
kprobe could cause a reentrant probe loop and trigger the "Unrecoverable KProbe
detected" panic.

> +		/* Save target addr before updating PC to SSOL slot */
> +		kcb->restore_pc = regs->pc;
> +	} else if (is_pc_insn(insn)) {
> +		simulate_pc(regs, insn);
> +		kcb->restore_pc = regs->pc;
> +		/* No SSOL is required here, so call post-process immediately. */
> +		post_kprobe_handler(p, kcb, regs);
> +		return;
> +	} else
> +		kcb->restore_pc = regs->pc + OPENRISC_INSN_SIZE;
> +
> +	if (p->ainsn.insn) {
> +		/* Disable IRQs before single stepping */
> +		local_irq_save(kcb->irq_flags);

[Severity: High]
Does this only disable interrupts for the exception handler itself, without
modifying regs->sr? Since OpenRISC's exception handler returns using regs->sr,
it appears the single-step out-of-line (SSOL) instruction would execute with
interrupts enabled, violating atomicity and allowing reentrant interrupts.

> +		instruction_pointer_set(regs, (unsigned long)p->ainsn.insn);
> +	} else {
> +		/*
> +		 * The instruction is a branch but delay slots are disabled.
> +		 * Simply call the post-handler.
> +		 */
> +		post_kprobe_handler(p, kcb, regs);
> +	}
> +}

[ ... ]

> +bool kprobe_breakpoint_handler(struct pt_regs *regs)
> +{

[ ... ]

> +	/*
> +	 * The breakpoint instruction was removed right after we hit it
> +	 * possibly by another cpu. If the original instruction was also
> +	 * a trap instruction then return to the trap handler for further
> +	 * processing, else no further processing is required.
> +	 */
> +	if (get_kernel_nofault(insn, addr) < 0
> +		|| (*addr & OPENRISC_MASK_TRAP) != OPENRISC_INSN_TRAP) {

[Severity: High]
Is this directly dereferencing *addr instead of using the safely read 'insn'
variable? If the probe is concurrently unregistered and the memory is unmapped,
dereferencing *addr directly could cause a kernel panic, defeating the safety of
get_kernel_nofault().

> +		preempt_enable_no_resched();
> +		return true;
> +	}
> +
> +	preempt_enable_no_resched();
> +	return false;
> +}

[ ... ]

> +int kprobe_fault_handler(struct pt_regs *regs, int trapnr)
> +{
> +	struct kprobe *cur = kprobe_running();
> +	struct kprobe_ctlblk *kcb = get_kprobe_ctlblk();
> +
> +	switch (kcb->kprobe_status) {
> +	case KPROBE_HIT_SS:
> +	case KPROBE_REENTER:
> +		/*
> +		 * The instruction being single-stepped caused a page fault.
> +		 * Reset the current KProbe and set PC to the probe's address.
> +		 * Then allow the page fault handler to continue as usual.
> +		 */
> +		instruction_pointer_set(regs, (unsigned long)cur->addr);

[Severity: Medium]
If a page fault occurs during the delay slot of an "l.jalr r9" instruction,
doesn't rewinding the PC to the branch instruction cause state corruption?
simulate_branch() permanently modifies regs->gpr[9], so re-executing the
branch after the fault handler returns would jump to the return address instead
of the original target.

> +
> +		if (kcb->kprobe_status == KPROBE_REENTER) {
> +			restore_previous_kprobe(kcb);

[Severity: High]
Does this KPROBE_REENTER path skip local_irq_restore() and
preempt_enable_no_resched()? This appears to leak the preemption count and
corrupt the lockdep state when a page fault occurs during a reentrant kprobe.

> +		} else {
> +			regs->sr |= kcb->irq_flags;
> +			local_irq_restore(kcb->irq_flags);
> +			reset_current_kprobe();
> +			preempt_enable_no_resched();
> +		}
> +		break;
> +	}
> +
> +	return 0;
> +}

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260930203129.51048-1-sahilcdq0@gmail.com?part=2

  reply	other threads:[~2026-09-30 20:46 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-04-07 18:56 [RFC 0/2] openrisc: Add support for KProbes Sahil Siddiq
2026-04-07 18:56 ` [RFC 1/2] openrisc: Add utilities and clean up simulation of instructions Sahil Siddiq
2026-04-14 17:11   ` Stafford Horne
2026-04-15  6:10     ` Sahil
2026-04-15  6:39     ` Masami Hiramatsu
2026-04-16  4:57       ` Sahil
2026-09-30 20:31   ` [PATCH v2 0/4] openrisc: Add support for KProbes Sahil Siddiq
2026-09-30 21:18     ` Sahil
2026-09-30 20:31   ` [PATCH v2 1/4] openrisc: Add utilities and clean up simulation of instructions Sahil Siddiq
2026-09-30 20:46     ` sashiko-bot
2026-09-30 20:31   ` [PATCH v2 2/4] openrisc: Add KProbes Sahil Siddiq
2026-09-30 20:46     ` sashiko-bot [this message]
2026-09-30 20:31   ` [PATCH v2 3/4] openrisc: Add unit tests for KProbes on branch instructions Sahil Siddiq
2026-09-30 20:41     ` sashiko-bot
2026-09-30 20:31   ` [PATCH v2 4/4] openrisc: Add Kretprobes Sahil Siddiq
2026-09-30 20:41     ` sashiko-bot
2026-04-07 18:56 ` [RFC 2/2] openrisc: Add KProbes Sahil Siddiq
2026-04-15  6:48 ` [RFC 0/2] openrisc: Add support for KProbes Masami Hiramatsu
2026-04-16  5:00   ` Sahil

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=20260930204605.389441F000FF@smtp.kernel.org \
    --to=sashiko-bot@kernel.org \
    --cc=linux-trace-kernel@vger.kernel.org \
    --cc=sahilcdq0@gmail.com \
    --cc=sashiko-reviews@lists.linux.dev \
    /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