Links to EBPF-related knowledge

summer · Posted on 10/20/2025 4:47:02 PM

This post was last edited by Summer on 2025-10-21 09:20

https://github.com/iovisor/bcc/blob/master/docs/kernel-versions.md ebpf对应的内核版本特性能解决什么问题 *

https://lore.kernel.org/bpf/ ebpf对应的内核ebpf补丁的信息讨论 *

https://juejin.cn/post/7084515511576313864 linux tracing system 各种tracing框架的对比分为前端，tracing框架，探针 *

summer · Posted on 10/20/2025 4:50:38 PM

Both EBPF and kernel modules correspond to the data source of kernel probes, not EBPF's own

summer · Posted on 10/20/2025 4:59:33 PM

Linux References: Brother Bird's Linux Author Taiwanese

The hyperlink login is visible.

summer · Posted on 10/20/2025 7:30:47 PM

https://www.cnblogs.com/revercc/p/17803876.html
The connection between eBPF's uprobe program and the kernel/events/uprobe.c is essentially that the eBPF mechanism reuses the kernel's native uprobe infrastructure to implement the hook function of user state functions. Specifically, eBPF's uprobe is an "application" of the kernel uprobe framework, which is linked through an internal kernel call chain and data structure.
Core connection: eBPF relies on the kernel uprobe framework to implement hooks
The kernel uprobe.c is the core implementation of the Linux kernel's native user-state probe (uprobe) and is responsible for:
Manage the registration and cancellation of user-state probes (e.g., register_uprobe(), unregister_uprobe()).
Handles breakpoint insertion (writing breakpoint instructions to the target function address, such as x86's int3).
Capture breakpoint trigger events (stuck in kernel state processing when a program is executed to a breakpoint).
Call a pre-registered callback function (i.e. hook logic).
The eBPF uprobe program (such as the example of hook libc.so you wrote) essentially registers a uprobe-based eBPF callback function with the kernel through the eBPF loader (e.g., bcc, libbpf), which completely relies on the infrastructure provided by uprobe.c.
Specific call chain: the flow from the eBPF program to uprobe.c
When you register a uprobe through an eBPF loader (such as bcc's attach_uprobe), the underlying process is as follows:
The eBPF loader initiates a registration request The loader (such as bcc's Python code) tells the kernel via a system call (such as bpf() or perf_event_open()) that "I want to hang an eBPF hook on the openat function of the libc.so" and passes the bytecode of the eBPF program.
Kernel Verification and Preparation of eBPF Programs The kernel eBPF verifier checks the legitimacy of the program to ensure it does not compromise kernel security. Once passed, load the eBPF program into the kernel and have an "eBPF callback function" (i.e. the uprobe_openat logic you wrote).
The reuse of uprobe.c's registration interface kernel will call the register_uprobe() function in uprobe.c, register a "native uprobe", and use the eBPF callback function as the "trigger handler" of this uprobe.
The key here is this: the essence of eBPF's uprobe is to bind a callback of type eBPF to the kernel's native uprobe.
uprobe.c inserts a breakpoint and waits for it to be triggered Uprobe.c writes a breakpoint instruction (such as x86's int3) to the user's state memory based on the registered target address (the address of openat in libc.so), and records the breakpoint's original instruction (for resuming execution after triggering).
Function calls trigger breakpoints, uprobe.c calls eBPF callbacks When the application calls libc.so:openat, executing the breakpoint instruction triggers a trap and falls into the kernel state. At this time:
The kernel calls the uprobe_handler() function (kernel processing logic) in uprobe.c.
uprobe_handler() will check the registration information corresponding to the breakpoint and find that it is bound to an eBPF callback, so it will call the eBPF program (i.e., the uprobe_openat you wrote).
After the eBPF program is executed (e.g., collecting parameters, writing to ringbuf), uprobe_handler() restores the original instruction and allows the program to continue execution.
Summary: The relationship between the two
kernel/events/uprobe.c is the underlying infrastructure, which provides core capabilities such as insertion, capture, and recovery of user state breakpoints, and is the foundation for all user state probes (including eBPF uprobe, gdb debugging, etc.).
The uprobe program of eBPF is an upper-layer application based on this infrastructure, which registers eBPF callback functions and allows the kernel to execute eBPF logic when uprobe is triggered, thereby achieving efficient user state function tracking.
In short: uprobe for eBPF is the "user" and uprobe.c is the "service provider", and the former relies on the latter to complete the registration, triggering, and execution of hooks.

[Safety Knowledge] Links to EBPF-related knowledge

Related Posts

Sections viewed