linux-kernel - Re: [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: <aRr1gXk1giE8TXvY@J2N7QTR9R3>
Date: Mon, 17 Nov 2025 10:14:25 +0000
From: Mark Rutland <mark.rutland@....com>
To: Ben Niu <niuben003@...il.com>
Cc: Catalin Marinas <catalin.marinas@....com>,
	Will Deacon <will@...nel.org>, tytso@....edu, Jason@...c4.com,
	Ben Niu <benniu@...a.com>, linux-arm-kernel@...ts.infradead.org,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH v2] tracing: Enable kprobe for selected Arm64 assembly

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).

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.

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 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.

Mark.