linux-kernel - Withdraw [PATCH v2] tracing: Enable kprobe for selected Arm64 assembly

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <aTjpzfqTEGPcird5@meta.com>
Date: Tue, 9 Dec 2025 19:32:29 -0800
From: Ben Niu <BenNiu@...a.com>
To: Mark Rutland <mark.rutland@....com>
CC: Ben Niu <niuben003@...il.com>, Ben Niu <benniu@...a.com>,
        Catalin Marinas
	<catalin.marinas@....com>,
        Will Deacon <will@...nel.org>, <tytso@....edu>, <Jason@...c4.com>,
        <linux-arm-kernel@...ts.infradead.org>, <linux-kernel@...r.kernel.org>
Subject: Withdraw [PATCH v2] tracing: Enable kprobe for selected Arm64
 assembly

On Mon, Nov 17, 2025 at 10:14:25AM +0000, Mark Rutland wrote:
> On Mon, Nov 03, 2025 at 10:52:35AM -0800, Ben Niu wrote:
> > When ftrace is enabled, a function can only be kprobe'd if
> >   (1) the function has proper nops inserted at the beginning
> >   (2) the first inserted nop's address is added in section
> >       __patchable_function_entries.
> >
> > See function within_notrace_func in kernel/trace/trace_kprobe.c
> > for more details.
> 
> As mentioned last time, this isn't accurate, and this is at the wrong
> level of abstraction. You're conflating kprobes with kprobes-based trace
> evnts, and you're describing the implementation details of ftrace rather
> than the logical situation that the function needs to be traceable via
> ftrace
> 
> This would be better summarized as:
> 
>   While kprobes can be placed on most kernel functions, kprobes-based
>   trace events can only be placed on functions which are traceable via
>   ftrace (unless CONFIG_KPROBE_EVENTS_ON_NOTRACE=y).

Thanks. I'm withdrawing this patch because my colleague suggested
a workaround that could trace __arch_copy_to_user/__arch_copy_from_user
without any changes for the kernel:

bpftrace -q -e '
BEGIN {
    printf("Attaching to __arch_copy_to_user...\n");
}

watchpoint:'"0x$(grep ' __arch_copy_to_user$' /proc/kallsyms | awk '{print $1}')"':4:x
{
    $n = reg("r2");
    @__arch_copy_to_user_sizes = hist($n);
}'

> IIUC from last time you only want this so that you can introspect
> __arch_copy_to_user() and __arch_copy_from_user(), so why can't you
> select CONFIG_KPROBE_EVENTS_ON_NOTRACE in your test kernel? That would
> require zero kernel changes AFAICT.

CONFIG_KPROBE_EVENTS_ON_NOTRACE has this help message, see
https://github.com/torvalds/linux/blob/c9b47175e9131118e6f221cc8fb81397d62e7c91/kernel/trace/Kconfig#L798,
that discourages production enablement, so we didn't turn it on.
 
> I'm not keen on doing this unless absolutely necessary, and as above it
> looks like we already have suitable options to make this possible for
> your use-case.

This patch is no longer needed.
 
> > This patch adds a new asm function macro SYM_FUNC_START_TRACE
> > that makes an asm funtion satisfy the above two conditions so that
> > it can be kprobe'd. In addition, the macro is applied to
> > __arch_copy_to_user and __arch_copy_from_user, which were found
> > to be hot in certain workloads.
> > 
> > Note: although this patch unblocks kprobe tracing, fentry is still
> > broken because no BTF info gets generated from assembly files. A
> > separate patch is needed to fix that.
> 
> As above, I'm not keen on doing this, and if it's largely incomplete, I
> think that's another nail in the coffin.
> 
> [...]
> 
> > +#ifdef CONFIG_ARM64_BTI_KERNEL
> > +#define BTI_C bti c;
> > +#else
> > +#define BTI_C
> > +#endif
> 
> Please note that we deliberately chose to always output BTI for asm
> functions to avoid a performance vaiability depending on whether BTI was
> enabled, so if we're going to change that, we must do that as a
> preparatory step with a clear rationale.

Ok, thanks for clarifying that.

> Mark.