linux-kernel - Re: [RFC PATCH bpf-next v1 0/3] bpf: Add BPF program type for overriding tracepoint probes

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] [thread-next>] [day] [month] [year] [list]

Message-ID: <e8e8b5e2-35fe-43cc-ba41-c84ccba189f7@vivo.com>
Date: Thu, 18 Sep 2025 20:33:22 +0800
From: Fuyu Zhao <zhaofuyu@...o.com>
To: Steven Rostedt <rostedt@...dmis.org>
Cc: ast@...nel.org, daniel@...earbox.net, andrii@...nel.org,
 martin.lau@...ux.dev, song@...nel.org, yonghong.song@...ux.dev,
 haoluo@...gle.com, jolsa@...nel.org, eddyz87@...il.com, kpsingh@...nel.org,
 sdf@...ichev.me, mhiramat@...nel.org, mathieu.desnoyers@...icios.com,
 shuah@...nel.org, willemb@...gle.com, kerneljasonxing@...il.com,
 paul.chaignon@...il.com, chen.dylane@...ux.dev, memxor@...il.com,
 martin.kelly@...wdstrike.com, ameryhung@...il.com,
 linux-kernel@...r.kernel.org, bpf@...r.kernel.org,
 linux-trace-kernel@...r.kernel.org, linux-kselftest@...r.kernel.org,
 yikai.lin@...o.com
Subject: Re: [RFC PATCH bpf-next v1 0/3] bpf: Add BPF program type for
 overriding tracepoint probes

Sorry, I just realized that I forgot to include the CC list in my first reply.
Resending with CCs. Apologies to Steven for the extra noise.

On 9/18/2025 3:30 AM, Steven Rostedt wrote:
> On Wed, 17 Sep 2025 15:22:39 +0800
> Fuyu Zhao <zhaofuyu@...o.com> wrote:
> 
>> Hi everyone,
>>
>> This patchset introduces a new BPF program type that allows overriding
>> a tracepoint probe function registered via register_trace_*.
>>
>> Motivation
>> ----------
>> Tracepoint probe functions registered via register_trace_* in the kernel
>> cannot be dynamically modified, changing a probe function requires recompiling
>> the kernel and rebooting. Nor can BPF programs change an existing
>> probe function.
> 
> I'm confused by what you mean by "tracepoint probe function"?
> 
> You mean the function callback that gets called via the "register_trace_*()"?
> 

Yes, that’s correct.
My earlier wording was not very precise — thanks for pointing that out.

>>
>> Overiding tracepoint supports a way to apply patches into kernel quickly
>> (such as applying security ones), through predefined static tracepoints,
>> without waiting for upstream integration.
> 
> This sounds way out of scope for tracepoints. Please provide a solid
> example for this.
> 

I appreciate your comment. The example I gave about security patches probably
wasn’t a good one here — I just meant to show the idea of changing kernel
behavior at runtime. Sorry for the confusion.

At the moment, I don’t have a solid real-world example to provide.
This work is still in an exploratory stage.

One possible use case is CPU core selection under certain scenarios. For example,
developers may want to experiment with alternative strategies for deciding
which CPU a task should run on to improve performance.

If a tracepoint is added as a hook point in this path, then overriding its
function callback could make it possible to dynamically adjust the
cpu-selection logic without rebuilding and rebooting the kernel.

The same mechanism could also be applied in other kernel paths where
developers want to make quick changes from user space.

>>
>> This patchset demonstrates the way to override probe functions by BPF program.
>>
>> Overview
>> --------
>> This patchset adds BPF_PROG_TYPE_RAW_TRACEPOINT_OVERRIDE program type.
>> When this type of BPF program attaches, it overrides the target tracepoint
>> probe function.
>>
>> And it also extends a new struct type "tracepoint_func_snapshot", which extends
>> the tracepoint structure. It is used to record the original probe function
>> registered by kernel after BPF program being attached and restore from it
>> after detachment. 
> 
> The tracepoint structure exists for every tracepoint in the kernel. By
> adding a pointer to it, you just increased the size of the tracepoint. I'm
> already complaining that each tracepoint causes around 5K of memory
> overhead, and I'd like to make it smaller.
> 
> -- Steve
> 

It is true that adding a pointer to the tracepoint structure increases
memory overhead. However, memory for "snapshot" pointer will only be allocated
after a BPF program is attached, and freed once it is dettached.

I am also considering whether it is possible to reuse existing structures
to reduce memory usage.

I'd be very grateful for any suggestions or guidance you might have.

Thanks,
Fuyu