B.5 辅助函数与上下文

在前面的探索中，我们在第一个 eBPF 示例里写下了 bpf_get_current_pid_tgid() >> 32 来获取触发事件的进程标识；而在反汇编中观察底层指令时，这条调用被编译成了一条操作码为 call 0xe 的指令。这两个看似分散的现象背后，共同指向了 Linux 内核为 eBPF 虚拟机所确立的核心执行准则：BPF 程序运行在裸机内核空间，既不能链接用户态的 C 标准库，也绝不被允许像传统内核模块那样随意跳转到内核的任意符号地址。为了在赋予系统观测与网络控制能力的同时守护内核底层的稳定性，内核向虚拟机提供了一组具有固定类型签名与安全契约的受控例程——辅助函数（helper function），并采用严格的静态编号进行调用分发。

然而，辅助函数仅仅构成了 eBPF 与内核环境交互的一个重要维度。与之相伴相生的另一个核心支柱，是每次程序被特定事件触发时由内核主动注入的“执行上下文”（context，通常在源码中声明为 ctx 指针）。在构建具备实际生产价值的观测工具时（例如捕获每一次进程执行 exec 行为的审计探针），开发者往往需要在一个探针内同时聚合并提取进程标识、父进程关系、当前命令名、时间戳以及指向完整路径的动态字符串。这些关键数据分别来自于辅助函数的返回值、上下文结构体的内部字段，以及受内核分页保护的动态内存深处。每一种数据的获取途径与解引用约束截然不同。清晰辨识内核内存的访问边界，理解上下文的内部构造，并根据宿主对象的生命周期选取合法的读取策略，是深入 eBPF 工业级编程的关键基石。

本节涉及的 BPF 程序均采用系统环境中的编译链条完成构建，目标文件均经过反汇编与底层字节校验；程序骨架由 bpftool gen skeleton 生成，用户态加载流程经过语法严格检查。完整示例工程归档于 code/系统编程/拓展B_eBPF/B_5_辅助函数与上下文/ 目录下。

1. 辅助函数是按编号调用的内核函数

1.1 声明是一个装着编号的函数指针

在现代 libbpf 的头文件体系中，bpf_helper_defs.h 为内核支持的每一个辅助函数都提供了一条严谨的 C 语言声明。该头文件通常由内核源码中的专用脚本解析文档自动提取生成，其实质就是内核暴露给 BPF 体系的辅助函数规范表：

zsh - bpf_helper_defs.h

$ grep -n 'bpf_get_current_pid_tgid)' bpf_helper_defs.h
378:static __u64 (* const bpf_get_current_pid_tgid)(void) = (void *) 14;

从 C 语言语法的角度审视这条声明：bpf_get_current_pid_tgid 被定义为一个具有静态作用域的常量函数指针，其所存储的值被强制转换为 (void *) 14。这里的数值 14 并不是内核虚拟内存空间中的真实函数地址，它对应着 Linux 内核在 BPF 辅助函数表中分配给该功能的固定编号。Clang 编译器在面向 BPF 目标架构进行代码生成时，对这种“带有函数原型的整型指针常量”拥有特殊的语义识别能力：当它发现代码在调用一个地址被硬编码为纯数值常量的函数指针时，会跳过常规的间接跳转指令（callx），直接提取该数值作为立即数，组装成一条合法的 BPF 直接调用指令。

我们可以通过一个仅调用该函数和 bpf_printk 的极简程序来观察底层的二进制表现：

#include "vmlinux.h"
#include <bpf/bpf_helpers.h>

char LICENSE[] SEC("license") = "Dual BSD/GPL";

SEC("tp/syscalls/sys_enter_write")
int show_ids(void *ctx)
{
    __u64 id = bpf_get_current_pid_tgid();

    (void)ctx;
    bpf_printk("tgid=%d tid=%d\n", (int)(id >> 32), (int)id);
    return 0;
}

编译完成后，使用 readelf -x 直接转储该程序对应的 ELF 节区内容：

zsh - readelf

$ clang -g -O2 -target bpf -mcpu=v3 -I. -c ids.bpf.c -o ids.bpf.o
$ readelf -x 'tp/syscalls/sys_enter_write' ids.bpf.o

Hex dump of section 'tp/syscalls/sys_enter_write':
 NOTE: This section has relocations against it, but these have NOT been applied to this dump.
  0x00000000 85000000 0e000000 bf030000 00000000 ................
  0x00000010 77030000 20000000 18010000 00000000 w... ...........
  0x00000020 00000000 00000000 b4020000 10000000 ................
  0x00000030 bc040000 00000000 85000000 06000000 ................
  0x00000040 b4000000 00000000 95000000 00000000 ................

首条指令的 8 个字节呈现为 85 00 00 00 0e 00 00 00。对照 BPF 指令编码规则：首字节操作码 0x85 标识调用操作；第二个字节高 4 位为源寄存器、低 4 位为目标寄存器，此处的 0x00 表示源寄存器为 0，即属于根据编号派发的辅助函数调用（若源寄存器为 1 则属于跨函数的 BPF 子程序局部跳转）；随后的偏移字段为零，最后的 4 个字节以小端序存储着立即数 0x0000000e，即十进制的 14。紧接着在节区偏移 0x30 处出现的 85000000 06000000，则是宏 bpf_printk 展开后所调用的底层例程 bpf_trace_printk，其分配的系统编号正是 6。

若指示编译器输出可读的汇编文本（-S），这两条调用关系将以更加直观的符号形态展现出来。中间交织的指令分别负责将 R0 的高低 32 位拆分并装填入用于参数传递的通用寄存器：

zsh - clang -S

show_ids:
	call 14
	r3 = r0
	r3 >>= 32
	r1 = show_ids.____fmt ll
	w2 = 16
	w4 = w0
	call 6
	w0 = 0
	exit

其中 r1 = show_ids.____fmt ll 是一条跨越两个指令槽位的 64 位立即数载入指令，在程序被加载入内核时，libbpf 会负责将只读数据节 .rodata 中格式化字符串的实际地址回填于此；而 w2 = 16 则传递了格式串的物理字节长度（包含末尾的空字符）。在汇编与机器字节层面，辅助函数从未保留任何 C 语言函数名或符号标签，它们仅仅以确凿的数字标识被深深刻印在字节码序列中。

在现代 Linux 内核头文件中，预定义声明的辅助函数已超过两百个，编号呈现连续递增的稳定特征：

zsh - 辅助函数的数量

$ grep -c '= (void \*) [0-9]' bpf_helper_defs.h
211
$ grep -o '= (void \*) [0-9]*' bpf_helper_defs.h | tail -1
= (void *) 211
$ grep -n '= (void \*) 211' bpf_helper_defs.h
4773:static long (* const bpf_cgrp_storage_delete)(void *map, struct cgroup *cgroup) = (void *) 211;

1.2 为什么不能调用任意内核函数

尽管 eBPF 程序运行在高度敏感的内核地址空间内部，但它并不具备传统内核可加载模块（LKM）那样自由解析和调用任意内核导出的外部符号的权力。这种审慎的架构设计源自两层不可妥协的安全与工程诉求：

其一，是保证系统二进制接口（ABI）的长期稳定性。内核内部的通用函数完全服务于内核子系统的演进，其命名、调用约定、参数顺序乃至结构体生命周期随时可能因性能调优或重构而发生剧烈变动。而辅助函数的编号一旦由社区确立，便成为内核向应用层交付的铁律承诺：其参数含义与返回值规范被固化在内核专有的 struct bpf_func_proto 结构体内，不可推翻。诸如用于 Map 查找的 bpf_map_lookup_elem（1 号）以及用于调试输出的 bpf_trace_printk（6 号），历经十数年内核版本的演进，其接口契约与调用语义始终如一，使得早期的二进制字节码依然能够平稳运行在现代内核上。

其二，是赋予内核验证器在静态加载期进行完备证明的技术能力。验证器在对提交的字节码进行全状态图推演时，每当识别到一条操作码为 0x85 的指令，便会立即依据其立即数索引到内核中对应的原型描述表。通过比对 bpf_func_proto 中标明的约束条件，验证器能够严格核验当前参数寄存器中的数据形态。例如，调用 bpf_probe_read_kernel 时，验证器会确认 R1 所指的接收端必须处于当前调用栈或 Map 内存中的可写区域，R2 必须是已知上限的常量尺寸（ARG_CONST_SIZE_OR_ZERO）；而在调用 bpf_get_current_comm 时，则必须保障缓冲区长度与传入参数精准匹配。倘若允许程序随意调用内核内部的任意函数，验证器因缺乏严密的元数据支持而无法推演其副作用，也就无从在静态阶段证明这次调用不会破坏内核内存完整性或诱发系统崩溃。

受限于 BPF 处理器的调用约定与寄存器设计，辅助函数最多只接受五个入参，分别由通用寄存器 R1 至 R5 承载，运算结果则一律通过寄存器 R0 传回。

在具体开发实践中，一个特定探针能否合法调用某项辅助函数，受到两道权限闸门的双重约束：

首要的约束是程序类型白名单。内核文档在阐述辅助函数时明确指出，这些函数按不同上下文量身定制了各自的可用子集，并不作为全局通用的公共库无条件开放。网络数据路径上的 XDP 程序需要极致的吞吐性能，因而被允许调用诸如 bpf_xdp_adjust_head（44 号）来动态调整数据包头指针；而用于调用栈回溯的 bpf_get_stackid（27 号）则专门服务于性能分析与事件跟踪探针，网络探针若尝试调用便会在验证阶段遭遇拒绝。不同挂载场景所开放的函数集合，在后续的程序类型专题中将按类系统梳理。

另一道约束则是开源许可证合规性。Linux 内核中的部分核心基础设施与深层跟踪能力带有鲜明的 GPL 约束标记，仅向声明了兼容开源协议的 BPF 程序开放。在 Linux 6.12 的内核源码实现中（如 kernel/trace/bpf_trace.c），诸如安全内存探测例程 bpf_probe_read_kernel、bpf_probe_read_user 以及跟踪日志打印函数 bpf_trace_printk 均被显式标明了 gpl_only = true 属性。若一个程序的节区许可证被声明为 "Proprietary"，当它试图调用这类受控函数时，内核验证器将在加载期立即驳回并记录 cannot call GPL-restricted function from non-GPL compatible program 的审计拒绝日志。因此，在通用开发实践中采用 "Dual BSD/GPL" 是一种广泛推荐的最佳实践。

若需要排查或探测当前宿主机环境所实际开放的辅助函数能力，可以通过两种方式切入。使用命令 bpftool feature list_builtins helpers 可以快速列出当前工具链本身内建知晓的辅助函数全集，该模式纯粹基于静态符号表，不触发真实的内核调用：

zsh - bpftool feature list_builtins

$ bpftool feature list_builtins helpers | wc -l
212
$ bpftool feature list_builtins helpers | sed -n '1,3p'
bpf_unspec
bpf_map_lookup_elem
bpf_map_update_elem
$ bpftool feature list_builtins helpers | tail -3
bpf_user_ringbuf_drain
bpf_cgrp_storage_get
bpf_cgrp_storage_delete

输出的首行 bpf_unspec 对应于索引 0 的保留占位符，其余 211 项与前述头文件声明严格吻合。若要真实探查当前正在运行中的内核所激活的可用函数，则应当执行 bpftool feature probe。该命令会在底层针对每一种程序类型模拟微型的加载流程，逐一验证各项辅助函数的可用性状态。而在用户态控制面代码中，libbpf 提供了 libbpf_probe_bpf_helper(prog_type, helper_id, NULL) 接口，支持在程序运行期动态查询特定组合的支持情况（返回 1 代表该特性在当前内核中就绪，0 代表不受支持）。

在工程中高频使用的基础辅助函数通常可归纳为以下几大经典类别：

用途	代表	编号
进程身份	bpf_get_current_pid_tgid、bpf_get_current_uid_gid、bpf_get_current_comm、bpf_get_current_task	14、15、16、35
时间	bpf_ktime_get_ns、bpf_ktime_get_boot_ns	5、125
读内存	bpf_probe_read_kernel、bpf_probe_read_kernel_str、bpf_probe_read_user、bpf_probe_read_user_str	113、115、112、114
调试输出	bpf_trace_printk、bpf_trace_vprintk	6、177
map 访问	bpf_map_lookup_elem、bpf_map_update_elem、bpf_map_delete_elem	1、2、3
网络	bpf_xdp_adjust_head、bpf_skb_load_bytes	44、26

2. 进程身份与时间

在几乎所有的系统级观测与事件跟踪场景中，首要解决的核心问题均是确定事件触发者的“主体身份”。在常规的用户态开发中，我们习惯于通过 POSIX API 中的 getpid() 获取当前进程号；但在 Linux 内核底层的调度模型中，这一概念需要被更加精准地拆解。在内核中，用于捕获触发者上下文的核心工具是 14 号辅助函数 bpf_get_current_pid_tgid()，它巧妙地在单个 64 位整型中压缩了两个关键维度：

用户态的 PID 与内核里的 tgid、pid

在 Linux 内核的任务调度架构中，统一采用 struct task_struct 来描述每一个最细粒度的调度实体。因此，内核原生语义下的 pid 实际上对应着具体的线程标识，即在用户态由 gettid() 获取的值；而用户态常规认知中的“进程标识”（getpid() 返回的值），在内核视角下实际上被称为线程组标识（Thread Group ID，即 tgid）。属于同一进程的所有并发线程，拥有各自独立的内核 pid，但共同维系同一个不变的 tgid。bpf_get_current_pid_tgid() 将这两项数据紧凑打包至一个 __u64 对象中：高 32 位承载进程所属的 tgid，低 32 位则承载当前执行线程的内核 pid。因此，若需要得到用户态视角的进程号，需右移 32 位提取高半段；若需要区分具体的并发线程，则直接截取低 32 位。

这种内核与用户态的概念对应关系，可以通过一个简单的多线程验证程序清晰观察。在代码 code/系统编程/拓展B_eBPF/B_5_辅助函数与上下文/id_demo.c 中，主线程派生出一个工作子线程，两端分别输出自身的进程与线程标识：

zsh - id_demo

$ gcc -std=c17 -Wall -Wextra id_demo.c -o id_demo -pthread
$ ./id_demo
main:   getpid() = 322162, gettid() = 322162
thread: getpid() = 322162, gettid() = 322163

从运行结果可见，主线程的进程标识与线程标识数值完全重合；而对于派生出的工作线程而言，其进程标识（tgid）依然牢牢锁定在 322162，而线程标识（tid）则递增为独立的 322163。当部署在内核中的 BPF 探针被执行时，提取返回值的高 32 位即可归并到同一个进程上下文，而提取低 32 位则能够精确追踪到具体的单线程控制流。这种区分在系统级剖析中至关重要：在跨函数的耗时统计探针中，为了避免多线程并发执行引发的计算交织，必须依靠唯一的低 32 位（线程 ID）作为键值进行事件关联配对；而在统计整体进程的内存分配与 IO 吞吐时，则统一采用高 32 位（进程 ID）作为汇聚键。

与此设计理念完全契合的，是 15 号辅助函数 bpf_get_current_uid_gid。它同样以紧凑的双拼形式返回执行实体的凭证信息：低 32 位承载当前任务的用户标识（UID），高 32 位承载所属用户组标识（GID）。此外，16 号辅助函数 bpf_get_current_comm 提供了将当前执行任务的进程简称（comm，通常对应于可执行文件名的前 16 个字符）安全复制到调用者指定缓冲区的功能，内核限制其写入长度固定为 16 字节（TASK_COMM_LEN），接收缓冲区必须处于局部栈空间或 Map 内存对象内，以便验证器确认其访问边界的绝对安全。

在时间度量领域，内核提供了两种不同语义的纳秒级高精度时钟源。5 号辅助函数 bpf_ktime_get_ns 返回自系统引导以来经历的绝对纳秒数，其内部对标内核的单调时钟（CLOCK_MONOTONIC），在系统进入深度挂起或休眠状态时该计数器会暂停累加；而 125 号辅助函数 bpf_ktime_get_boot_ns 则对标系统启动时钟（CLOCK_BOOTTIME），将系统休眠挂起的物理时间一并纳入计算。这两项接口设计的核心定位均是用于精确度量两次事件之间的执行耗时与时间间隔，它们并不直接反映人类日常生活中的年月日墙上时钟（Wall Clock）。如果需要将跟踪记录与绝对真实时间完成对齐，通常需要用户态协同程序在启动时读取一次当前基准时刻，再与纳秒差值完成换算。

将上述身份与时间提取接口加以汇聚，便能构成一个基础但功能完备的上下文标识探针：

SEC("tp/syscalls/sys_enter_write")
int show_identity(void *ctx)
{
    __u64 id;
    __u64 ug;
    __u64 now;
    char comm[16];

    (void)ctx;
    id = bpf_get_current_pid_tgid();
    ug = bpf_get_current_uid_gid();
    now = bpf_ktime_get_ns();
    bpf_get_current_comm(comm, sizeof(comm));

    bpf_printk("tgid=%u tid=%u uid=%u gid=%u comm=%s t=%llu\n",
               (__u32)(id >> 32), (__u32)id, (__u32)ug, (__u32)(ug >> 32), comm,
               now);
    return 0;
}

在该探针被编译为机器指令后，其核心主体呈现为 call 14、call 15、call 5、call 16 以及最终的 call 177。前四项调用分别完成了进程身份、权限凭据、单调时刻以及任务名称的就地捕获；最后的输出之所以对应于操作码为 177 的辅助函数，是因为当 bpf_printk 宏所绑定的动态参数超过三个时，头文件中的宏机制会自动将调用分发提升至支持可变参数格式的 bpf_trace_vprintk，通过栈内存将参数集合整块递交内核。

单选

bpf_get_current_pid_tgid() 返回值的低 32 位是什么？

进程 ID，也就是用户态的 getpid()

线程 ID，也就是用户态的 gettid()

用户 ID

CPU 编号

3. 读内存：哪些能直接读

在传统的 C 语言系统开发中，只要手中持有一个指针，开发者便习惯性地认为可以通过 *p 或 -> 运算符对目标内存发起解引用。然而在 eBPF 运行时的语义视界中，指针解引用的合法性边界被施加了严格的数学审查。内核验证器在程序静态分析阶段，会对每一条内存加载指令（如 LDX）追溯其地址来源：只有当指针所指向的内存区间被验证器明确识别为具有安全类型契约、且访问边界在编译期或逻辑证明中完全可控时，原生的直接解引用才被允许；对于其余所有未知或动态的内存地址，程序必须交由内核专用的辅助探测例程进行受控读取。这些探测例程在底层依托硬件页表异常处理机制，即便遭遇非法指针或未映射地址也仅返回负数错误码，绝不会导致内核发生致命的缺页恐慌。

内存	能不能直接读	读法
ctx 指向的记录	能	ctx->field，验证器按程序类型检查字段偏移与权限
栈	能	局部对象与数组，边界由验证器全生命周期跟踪
map 的值	判空后能	bpf_map_lookup_elem 的返回值，详见 B.6
带 BTF 类型的指针	能	fentry 参数、bpf_get_current_task_btf 的返回值，详见 B.8
其它内核内存	不能	bpf_probe_read_kernel、bpf_probe_read_kernel_str
用户空间内存	不能	bpf_probe_read_user、bpf_probe_read_user_str

前四类内存之所以能够被 BPF 虚拟机直接寻址解引用，根源在于验证器在分析时能够完全掌握其内存来源与边界拓扑：上下文 ctx 的内存模型由程序挂载类型严格界定；栈空间由 Clang 编译器在 512 字节的静态限额内分配并生成确切的偏移记录；Map 的查找结果在显式排除空指针后，其对象结构体大小在加载时便已注册；而附带 BTF 类型标识的指针则携带着内核完备的类型元数据。相反，后两类内存在验证器眼中仅仅是一个未知的 64 位裸数值，验证器无从推断该数值是否指向合法地址、对应的数据结构跨度有多大，更无法保证该内存页在执行瞬间是否常驻于物理内存中。

在实际探针中遍历多级指针是读取内核内存的典型场景。例如，调用 35 号辅助函数 bpf_get_current_task() 能够获取当前正在 CPU 上执行的任务控制块地址，但在验证器的类型推演系统中，该返回值在未开启特权 BTF 的常规上下文中仅被归类为无类型的“标量”（scalar）。若要沿着它进一步探查父进程的标识，必须借助 bpf_probe_read_kernel 分步读取：

struct task_struct *task;
struct task_struct *parent;
pid_t ppid;

task = (struct task_struct *)bpf_get_current_task();
bpf_probe_read_kernel(&parent, sizeof(parent), &task->real_parent);
bpf_probe_read_kernel(&ppid, sizeof(ppid), &parent->tgid);

上述逻辑被 Clang 编译后，在机器码中精准呈现为 call 35、call 113、call 113 这样连续调用内核探测函数的指令序列。现代 libbpf 提供了 BPF_CORE_READ 宏，允许将这种繁杂的级联读取折叠为一行声明：

ppid = (pid_t)BPF_CORE_READ(task, real_parent, tgid);

宏在预处理后同样会展开为多段嵌套的 bpf_probe_read_kernel 调用，底层汇编指令序列与手动分步书写完全一致。其核心优势在于：BPF_CORE_READ 会在目标文件的重定位节中自动记录字段的访问重定位信息，当程序跨内核版本迁移时，libbpf 能够根据目标内核的实际 BTF 布局动态修正结构体字段偏移，而无须硬编码固定的偏移数值。

倘若我们尝试像普通内核驱动那样直接使用级联解引用，将其写为 ppid = task->real_parent->tgid;，编译器依然能够通过并生成原生的内存加载指令：

zsh - 直接解引用

call 35
r1 = *(u64 *)(r0 + 2448)
w3 = *(u32 *)(r1 + 2436)
call 6

然而，当这段字节码被提交给内核验证器时，验证流程将在第二条指令 r1 = *(u64 *)(r0 + 2448) 处立即中断。验证器会抛出 R0 invalid mem access 'scalar' 错误——由于 R0 寄存器内的返回值未携带受信任的内存类型标识，试图将其作为内存基地址进行直接偏移解引用会被直接拦截。此外，反汇编中出现的 2448 和 2436 等具体数值，是当前编译环境所采用内核的内部排布，在不同内核发行版中这些字段的物理偏移随时可能漂移，这也是直接访存无法实现跨内核分发的重要原因。

对于字符串类型的数据，内核提供了带有 _str 后缀的受控探测函数。该例程在读取过程中持续扫描空字符（\0），并在遇到终止符时主动结束复制，返回值指示实际写入缓冲区的字节总数。当需要探查来源于用户空间的内存数据时，必须选用 _user 版本的探测函数。例如在 sys_enter_openat 系统调用入口处，用户态传入的路径参数指向用户空间虚拟地址，此时内核尚未将其拷入内核空间，唯有依赖 bpf_probe_read_user_str 才能安全提取路径内容：

单选

在 sys_enter_openat 的 tracepoint 程序里，要读出第二个参数指向的路径字符串，应该用哪个辅助函数？

bpf_probe_read_kernel_str，内核里统一用这个

bpf_probe_read_user_str，这个地址属于用户空间

直接解引用 ctx->args[1]，ctx 里的指针都是安全的

bpf_get_current_comm，它专门读路径

4. 上下文就是 R1

当 BPF 程序被特定事件唤醒并开始执行第一条指令时，通用寄存器 R1 中已经由内核运行时注入了当前事件的“上下文指针”，这一约定在 BPF 虚拟机的底层 ABI 中是全局固化的。在不同的挂载点下，R1 指向的内存构造呈现出截然不同的形态。

上下文 ctx 的具体内存布局完全取决于程序的挂载类型（如 Tracepoint、Kprobe 或 Fentry）。验证器会在静态分析时严格监督每一次针对 ctx 偏移的直接解引用，包括字段偏移量是否合规、读取的数据宽度是否越界以及当前上下文是否允许写入。因此，相同的 C 语言表达式在不同类型的程序中具备完全相异的物理语义；将一个本用于 Tracepoint 的解引用代码直接移植到 XDP 程序中，验证器会因上下文类型不匹配而拒绝加载。

4.1 tracepoint 的 ctx

在静态跟踪点（Tracepoint）探针中，ctx 指向内核在事件触发点预先格式化完毕的一段事件记录结构体。在通过 vmlinux.h 展开的头文件定义中，内核为每一个静态事件自动派生了专有的 struct trace_event_raw_<事件名> 结构，其字段排布与系统 tracefs 虚拟文件系统中该事件的 format 文件完全对应：

zsh - vmlinux.h

$ grep -A 5 'struct trace_event_raw_sys_enter {' vmlinux.h
struct trace_event_raw_sys_enter {
	struct trace_entry ent;
	long int id;
	long unsigned int args[6];
	char __data[0];
};

$ grep -A 6 'struct trace_event_raw_sched_process_exec {' vmlinux.h
struct trace_event_raw_sched_process_exec {
	struct trace_entry ent;
	u32 __data_loc_filename;
	pid_t pid;
	pid_t old_pid;
	char __data[0];
};

对于系统调用入口事件而言，其结构整齐而统一：id 承载当前触发的系统调用号，紧随其后的 args[6] 数组则容纳了由用户态传递的 6 个原生寄存器参数。而在诸如进程创建与执行的 sched_process_exec 事件中，结构体内包含了一个名为 __data_loc_filename 的特殊整型字段。在内核事件定义中，带有 loc 标记的字段代表着动态长度字符串在当前跟踪记录中的定位指针：

• 低 16 位编码了该字符串起始地址相对于当前事件结构体首地址的字节偏移量；
• 高 16 位则记录了该字符串的实际字节跨度（包含空终止符）。

这种设计是内核应对动态长度追踪记录的标准化手段：事件定义中的宏机制将动态字符串先抽象为动态数组，再具象为一个 32 位整型对象，以便在编译期维持结构体骨架尺寸的确定性。在运行期，内核将动态数组实际追加在固定字段末尾，并将相对位移填入低 16 位。

因此，要在 Tracepoint 探针中读取可执行文件名，必须采用两阶段解析法：首先计算目标字符串的绝对内存起始地址 (const char *)ctx + (ctx->__data_loc_filename & 0xFFFF)，随后将该地址投递给辅助例程 bpf_probe_read_kernel_str 进行安全复制。这一处理过程在反汇编中清晰可辨：

zsh - clang -S

r3 = r1
w1 = *(u32 *)(r3 + 8)
w1 &= 65535
r3 += r1
r1 = r6
w2 = 64
call 115

指令 *(u32 *)(r3 + 8) 准确命中了位于结构体偏移 8 字节处的 __data_loc_filename（前 8 字节为通用的 trace_entry 头部）；随后的位与指令 w1 &= 65535 剥离出低 16 位的物理偏移，并通过 r3 += r1 将偏移与 R1 上下文基址相加，得到目标字符串的首地址。这一段内存虽然物理上紧随在结构体尾部，但由于其具体偏移是在运行期动态计算所得，超出了验证器基于常量偏移分析的安全防线，因此必须借由内核辅助函数完成最终的内容获取。

单选

tracepoint 结构体里的 __data_loc_filename 字段应该怎么读？

它就是一个普通指针，直接解引用即可

取低 16 位作为相对 ctx 的偏移，加上 ctx 后交给 bpf_probe_read_kernel_str

取高 16 位作为偏移，低 16 位是长度

它保存的是字符串的绝对内核地址，直接打印

4.2 kprobe 的 ctx

在动态内核探针（Kprobe）机制中，ctx 指向 struct pt_regs 结构体，记录了目标内核函数被触发瞬间宿主 CPU 的物理寄存器上下文快照。在 x86-64 架构的标准系统调用与函数调用约定中，前六个整型参数依序存放在寄存器 di、si、dx、cx、r8 和 r9 中。映射到 Linux 内核的 struct pt_regs 结构体排布上，它们对应的字节偏移分别为 112、104、96、88、72 与 64 字节。这些偏移并不随着参数序号单调递增，原因是 Linux 内核为了中断恢复的便利性，在栈上压入通用寄存器时采取了逆序排列。

手写这些体系结构高度相关的物理偏移极易引入隐蔽缺陷。libbpf 的 bpf_tracing.h 提供了便利的 BPF_KPROBE 封装宏：

SEC("kprobe/do_unlinkat")
int BPF_KPROBE(unlink_ctx, int dfd, struct filename *name)
{
    bpf_printk("dfd=%d name=%s\n", dfd, BPF_CORE_READ(name, name));
    return 0;
}

该宏将开发者编写的逻辑包装在一个接收 struct pt_regs *ctx 参数的底层函数内部，自动根据目标架构的调用约定从 pt_regs 的对应偏移槽位中提取寄存器数值，并将其强制转化为声明所指定的类型。经过 Clang 编译后，参数提取与安全读取的过程如下展开：

zsh - clang -S

r3 = *(u64 *)(r1 + 104)
r2 = 0
r3 += r2
r6 = *(u64 *)(r1 + 112)
r1 = r10
r1 += -8
w2 = 8
call 113
r4 = *(u64 *)(r10 - 8)
call 6

汇编中的 call 113 正是宏 BPF_CORE_READ(name, name) 展开的结果：它先从栈帧中借用临时空间，通过 bpf_probe_read_kernel 将位于 name->name 处的内部指针安全拷入栈内，随后才装入 R4 用于最终格式化输出。为什么此处不能直接对 name 进行指针解引用？因为在验证器的认知中，从 pt_regs 寄存器镜像中提取出来的任何数据，都只是一段不具备可信类型凭证的未加工整型数值，无法当作可直接解引用的内核指针。

由于 BPF_KPROBE 的参数提取强依赖于底层 CPU 的寄存器结构，因此在编译携带此类宏的程序时，必须显式定义宿主架构宏（如 -D__TARGET_ARCH_x86），否则编译流程将直接在预处理阶段中断。

4.3 fentry 的 ctx

相比于 Kprobe 基于物理断点指令（如 INT3）并捕获全局寄存器快照的传统方式，现代 Linux 内核引入的 Fentry 与 Fexit 机制依托于专有的 BPF 蹦床（trampoline）技术。当被观测函数被执行时，蹦床代码直接拦截调用栈，并严格对照 BTF 中记录的内核函数原型，将各入参按照线性顺序打包为一个紧凑的 64 位数组传递给 BPF 程序。通过配合 BPF_PROG 宏，开发者能够以几乎与原生 C 函数无异的直观语法访问参数：

SEC("fentry/do_unlinkat")
int BPF_PROG(unlink_ctx, int dfd, struct filename *name)
{
    bpf_printk("dfd=%d name=%s\n", dfd, name->name);
    return 0;
}

在 Fentry 模式下，表达式 name->name 回归了原生结构体解引用。Clang 仅生成了一条附带 CO-RE 重定位标记的直接内存加载指令，省去了 bpf_probe_read_kernel 辅助函数的介入。将两种探针的反汇编并置对比，其底层路径的差异一目了然：

❌ kprobe：从 pt_regs 取，读成员要辅助函数

r3 = *(u64 *)(r1 + 104)     # name，第二个参数（si）
r6 = *(u64 *)(r1 + 112)     # dfd，第一个参数（di）
call 113                    # BPF_CORE_READ 读 name->name
r4 = *(u64 *)(r10 - 8)      # 取回读到的指针
w3 = w6                     # dfd 作为第一个打印参数
call 6                      # bpf_printk

✅ fentry：参数带类型，可以直接读

r2 = *(u64 *)(r1 + 8)       # name
r4 = *(u64 *)(r2 + 0)       # name->name，直接加载
r3 = *(u64 *)(r1 + 0)       # dfd
call 6                      # bpf_printk

在 Fentry 模型中，R1 上下文数组的索引 0 精确对应着被挂载函数的首个参数（dfd 位于 r1 + 0），索引 1 则对应第二个参数（name 位于 r1 + 8）。这种线性规整的内存排布摆脱了硬件物理寄存器的逆序限制，因而无论在何种 CPU 架构下编译 Fentry 程序，均无须指定体系结构宏。更重要的是，由于蹦床在注入上下文时深度绑定了 BTF 类型系统，验证器能够确认 R2 寄存器内部承载着合法的 struct filename * 指针，因而直接放行了针对其结构体成员的解引用操作，使执行开销大幅下降。

在网络可观测性与数据包过滤领域，上下文结构体又被赋予了专有的形态：在 XDP 层对应于 struct xdp_md，在 TC 流量控制层则对应于 struct __sk_buff，相关的内存模型将在后续网络专题中系统呈现。

5. 完整示例：记录每次 exec

将前文探讨的进程凭据捕获、动态跟踪记录解析以及基于内核控制块的跨级追踪融汇贯通，我们便能够构建出一个具备实用价值的进程执行审计探针：每当系统内部发生进程载入新映像（即触发 exec 系列系统调用）的行为时，探针能够就地捕获该实体的进程标识、父进程标识、执行用户、简短命令名以及磁盘上的完整可执行文件路径。完整的工程代码存放在 code/系统编程/拓展B_eBPF/B_5_辅助函数与上下文/ 目录下，其内核态探针的核心实现如下：

// SPDX-License-Identifier: GPL-2.0 OR BSD-3-Clause
#include "vmlinux.h"
#include <bpf/bpf_helpers.h>
#include <bpf/bpf_core_read.h>

char LICENSE[] SEC("license") = "Dual BSD/GPL";

SEC("tp/sched/sched_process_exec")
int handle_exec(struct trace_event_raw_sched_process_exec *ctx)
{
    struct task_struct *task;
    char filename[256];
    char comm[16];
    __u64 id;
    __u32 uid;
    __u32 offset;
    pid_t pid;
    pid_t ppid;

    id = bpf_get_current_pid_tgid();
    pid = (pid_t)(id >> 32);
    uid = (__u32)bpf_get_current_uid_gid();
    bpf_get_current_comm(comm, sizeof(comm));

    task = (struct task_struct *)bpf_get_current_task();
    if (task == 0) {
        return 0;
    }
    ppid = (pid_t)BPF_CORE_READ(task, real_parent, tgid);

    offset = ctx->__data_loc_filename & 0xFFFF;
    bpf_probe_read_kernel_str(filename, sizeof(filename),
                              (const char *)ctx + offset);

    bpf_printk("EXEC pid=%d ppid=%d uid=%u comm=%s file=%s\n", pid, ppid, uid,
               comm, filename);
    return 0;
}

在这段紧凑而真实的内核探针代码中，有若干关键设计细节体现了受限 C 语言的工程考量：

首先是入参上下文的具体化绑定。代码中将 ctx 显式声明为具体结构体指针 struct trace_event_raw_sched_process_exec *，取代了通用的 void *。这种做法让编译器能够直接推导出 ctx->__data_loc_filename 与 ctx->pid 等成员的精准结构体偏移量，验证器也能够基于已注册的 Tracepoint 元数据迅速通过边界检查，省去了手动进行指针平移与强制转换的繁琐步骤。

其次是防御性判空。在调用 bpf_get_current_task() 获得当前任务控制块指针后，代码立即进行了 task == 0 的零值判定。尽管在验证器的原生推演中该返回值被归类为无状态的标量对象、即便省略判空也不会阻断程序的静态加载，但在高负载或处于特殊调度周期的内核环境中，引入这一防御检查依然是保障运行安全的良好编程习惯。

第三是动态定位字段的边界解析。对于 __data_loc_filename，逻辑中仅截取了低 16 位以计算相对位移。高 16 位所携带的理论长度信息并未显式传入，原因是 bpf_probe_read_kernel_str 在拷贝过程中内置了空终止符检测；即便内核中传递的路径超出了预留的 256 字节局部栈缓冲区，探测例程也能平稳截断，确保字符串以安全的空字符结尾并防止栈内存溢出。

最后是输出例程的分发。由于 bpf_printk 宏所绑定的动态参数多达 5 个，Clang 预处理器会自动将其展开为针对 177 号辅助函数 bpf_trace_vprintk 的底层调用。通过观察编译器生成的字节码，可以完整还原其底层的调用时序：

指令序号	调用	用途
1	call 14	bpf_get_current_pid_tgid，就地获取复合身份标识
3	call 15	bpf_get_current_uid_gid，提取执行用户凭证
8	call 16	bpf_get_current_comm，复制任务简名
9	call 35	bpf_get_current_task，获取当前任务控制块基址
17	call 113	BPF_CORE_READ 首步，解引用 task->real_parent
24	call 113	BPF_CORE_READ 次步，读取父进程的 tgid
34	call 115	bpf_probe_read_kernel_str，读取完整路径字符串
53	call 177	bpf_trace_vprintk，通过栈传参格式化输出

在指令编号 34（call 115）与指令编号 53（call 177）之间，编译器插入了连续 5 条形如 *(u64 *)(r10 - N) 的栈写操作。这是因为 BPF 虚拟机的参数传递寄存器（R1~R5）无法直接承载超出数量限制的参数；Clang 依照可变参数规范将待打印的数值紧凑排布在以 R10 为基准的栈帧槽位中，随后仅向 177 号辅助函数传递包含格式串、长度以及栈顶参数数组指针的元数据。

用户态控制面程序严格遵循经典的生命周期管理四部曲。通过自动化骨架生成工具，目标文件导出的程序实体被严密组织在结构体骨架中：

zsh - bpftool gen skeleton

$ bpftool gen skeleton execlog.bpf.o > execlog.skel.h
$ sed -n '13,24p' execlog.skel.h
struct execlog_bpf {
	struct bpf_object_skeleton *skeleton;
	struct bpf_object *obj;
	struct {
		struct bpf_map *rodata;
	} maps;
	struct {
		struct bpf_program *handle_exec;
	} progs;
	struct {
		struct bpf_link *handle_exec;
	} links;

用户态宿主程序负责依次调用 execlog_bpf__open()（解析 ELF 节区并初始化对象）、execlog_bpf__load()（提交内核验证并创建内部 Map 实体）、execlog_bpf__attach()（将探针正式挂载至内核跟踪点），并在捕获退出信号后通过 execlog_bpf__destroy() 完成资源释放。通过标准的构建管线即可生成独立的可执行文件：

zsh - build

$ clang -g -O2 -target bpf -mcpu=v3 -I. -c execlog.bpf.c -o execlog.bpf.o
$ bpftool gen skeleton execlog.bpf.o > execlog.skel.h
$ cc -std=c17 -Wall -Wextra execlog.c -o execlog $(pkg-config --cflags --libs libbpf)

启动加载程序并在终端中持续监控全局跟踪管道：

zsh - run

$ sudo ./execlog
tracing exec... hit Ctrl-C to end

在另一个控制台窗口执行 cat /sys/kernel/tracing/trace_pipe，即可实时观察系统中每一次可执行文件调用的记录。管道中打印的内容前缀统一标识为 bpf_trace_printk:（底层与 bpf_trace_vprintk 共享同一事件流），其中 comm 字段记录了新映像的执行名，而 file 字段则输出了包含目录层级的完整启动路径。这种基于 tracepoint 的轻量级拦截与提取，构成了主机安全审计监控系统的常见基础组件。

6. kfunc

辅助函数机制依托于严格固化的静态编号与全内核统一的原型注册表，虽然为整个 eBPF 生态提供了稳定的长期 ABI 承诺，但这种设计也天然伴随着较高的扩展门槛：每向内核引入一项新特性，社区就必须在核心源码树中申请一个不可回收的全新编号，且参数签名严格受制于验证器预置的原型分类。为了破除这种接口扩张瓶颈，现代 Linux 内核引入了更加直接的例程调用机制——kfunc（Kernel Functions）。

kfunc 允许 eBPF 程序直接调用在内核源码中以 __bpf_kfunc 标记并注册进特定集合的内核内部函数。以进程控制块查询例程 bpf_task_from_pid 为代表，它允许探针直接根据 PID 获取对应的内核对象引用。

与这种灵活性相伴的，是对接口稳定性的折中。Linux 内核文档在论述 kfunc 时明确指出：kfunc 属于内核子系统与 BPF 子系统之间的内部接口，不承担类似辅助函数那样长期固定的对外 ABI 承诺。随着内核架构的迭代演进，特定 kfunc 的函数名、参数排列甚至存在性本身都可能在不同次版本之间发生调整。

在源码书写上，kfunc 表现为普通的 C 语言外部函数声明（extern），并附带 __ksym 与 __weak 弱符号属性。在基于最新内核生成的 vmlinux.h 中，相关的原型已经完备定义：

zsh - kfunc 原型

$ grep -n 'bpf_task_from_pid\|bpf_task_release' vmlinux.h
127682:extern struct task_struct *bpf_task_from_pid(s32 pid) __weak __ksym;
127684:extern void bpf_task_release(struct task_struct *p) __weak __ksym;

在 BPF 探针中调用 kfunc 与调用普通 C 函数完全一致：

struct task_struct *task;

task = bpf_task_from_pid(1);
if (task == 0) {
    return 0;
}
bpf_printk("tgid=%d\n", task->tgid);
bpf_task_release(task);

经过编译器处理后，该调用在生成的 ELF 目标文件中记录为外部符号引用，并伴随着一条专有的 R_BPF_64_32 重定位项：

zsh - readelf -r

$ readelf -r kf.o

Relocation section '.reltp/sched/sched_process_exec' at offset 0x8bae0 contains 3 entries:
  Offset          Info           Type           Sym. Value    Sym. Name
000000000008  000c0000000a R_BPF_64_32       0000000000000000 bpf_task_from_pid
000000000020  000500000001 R_BPF_64_64       0000000000000000 .rodata
000000000050  000d0000000a R_BPF_64_32       0000000000000000 bpf_task_release

这一重定位特征体现了 kfunc 与辅助函数在底层机制上的差异：辅助函数的编号被直接内联固化在指令立即数中，不产生任何重定位需求；而 kfunc 则依托于符号解析体系。libbpf 在将程序载入内核的过程中，会根据符号名称在目标宿主内核的 BTF 类型库中检索其真实标识，并将 BPF 指令的源寄存器动态设置为标识伪调用的 BPF_PSEUDO_KFUNC_CALL，同时将立即数改写为目标函数在当前内核中的实际 BTF ID。若当前内核中缺失该函数符号，libbpf 会在加载时拦截并上报外部例程未识别的错误。

此外，kfunc 还引入了资源对象的生命周期受控机制。以 bpf_task_from_pid 为例，内核在将其导出为 kfunc 时附带了 KF_ACQUIRE | KF_RET_NULL 属性标记。该函数在运行期会增加目标任务对象的引用计数，且在查找失败时可能返回空指针。内核验证器在推演执行流时，会启动专有的引用计数追踪状态机，强制要求代码必须先进行非空判定，并在程序退出前的每一条可达分支上显式调用 bpf_task_release 释放该引用。任何遗漏释放的执行路径都会被验证器当场拦截，从而在编译与加载期杜绝内核对象的引用计数泄漏。

在实际工程选型中，通常优先选用具备稳定 ABI 承诺的传统辅助函数。例如当前上下文中若仅需获取正在执行的任务控制块，直接调用 35 号辅助函数 bpf_get_current_task 兼顾了跨版本兼容性与执行效率；当所需的深层内核能力尚未被传统辅助函数覆盖时，再引入 kfunc 并配合 __weak 弱符号机制做好跨版本兼容处理。

7. 习题

7.1 巩固

#46501

⚡1⏳1

下面这段十六进制字节流取自某次编译后 tp/syscalls/sys_enter_write 节区的前 32 个字节：

0x00000000 85000000 0e000000 bf030000 00000000
0x00000010 77030000 20000000 18010000 00000000

请对照 B.4 所阐述的指令编码格式，逐字段拆解前两条指令，指出每条指令的操作码（opcode）、源寄存器、立即数，以及该立即数所映射的辅助函数名称。在此基础上进一步分析：若将首条指令中的 call 14 替换为 call 15，程序的运行行为将发生怎样的变化。

#46502

⚡2⏳1

前文示例 show_identity 输出了进程的 tgid、tid、uid、gid、comm 以及单调时钟读数。请对其进行如下扩展改造：

• 将时间戳获取方式替换为 bpf_ktime_get_boot_ns()，并阐述该函数与 bpf_ktime_get_ns() 在何种系统状态下会产生不同的时间读数；
• 增加对父进程 tgid 的采集与输出，要求结合 bpf_get_current_task() 的返回值与 BPF_CORE_READ 宏完成提取。

完成编译后，借助 readelf -x 或编译器的 -S 汇编输出，核实父进程信息读取逻辑是否被编译为 call 113 指令，并整理出你在反汇编输出中观察到的完整辅助函数调用序列。

7.2 编程

#46503

⚡2⏳2

编写一个挂载于 sys_enter_openat 跟踪点的 eBPF 探针程序，在系统每次打开文件时输出一行包含 tgid、线程 ID 以及目标文件路径的跟踪记录。具体实现需满足以下约束：

• 目标文件路径必须调用 bpf_probe_read_user_str 从用户空间读取，栈上接收缓冲区大小设为 256 字节；
• 当字符串读取返回负值错误码时直接终止当前探针逻辑，避免输出残缺或未初始化的路径内容；
• 使用 bpftool gen skeleton 生成控制面骨架头文件，用户态加载器沿用 B.3 介绍的四步标准生命周期，无须设置额外的事件过滤逻辑。

验证方式：在测试环境中启动加载程序，随后在另一终端窗口执行 cat /etc/hostname，核实跟踪输出中是否包含 tgid 等于 cat 进程号、路径为 /etc/hostname 的记录；再执行一次 ls 命令，观察其打开当前目录时的调用事件是否同样被准确捕获。

#46504

⚡3⏳3

在示例 execlog.bpf.c 中，父进程 tgid 的提取采用了 BPF_CORE_READ(task, real_parent, tgid)。请围绕这一逻辑编写两个对照变体：

• 变体一：显式调用两次 bpf_probe_read_kernel，分步读取 real_parent 指针与 tgid 字段；
• 变体二：直接采用 C 语言原生级联解引用语法 task->real_parent->tgid。

将三份代码分别编译为目标文件并对比反汇编结果（可使用 clang -S 或 objdump -d）：核实前两种写法生成的辅助函数调用序列是否完全一致，而变体二中不再包含 call 113 指令。最后尝试加载变体二，记录内核验证器给出的具体报错信息，并指出报错位置对应于反汇编中的哪一条指令。

#46505

⚡3⏳3

在内核生成的 vmlinux.h 中并未单独定义 trace_event_raw_sched_process_exit，sched_process_exit 事件实际复用了模板结构体 struct trace_event_raw_sched_process_template（包含 comm、pid、prio 三个核心字段）。请基于该上下文结构体编写一个跟踪程序，在任意进程退出时采集并打印：

• 退出进程自身的 comm 名称与 pid；
• 其父进程的 comm 名称（结合 BPF_CORE_READ 与 bpf_probe_read_kernel_str 从任务控制块中提取）。

验证方式：程序挂载运行后，在另一终端执行 true 命令，观察跟踪管道中是否出现 comm=true 的退出记录，并确认其父进程 comm 字段是否与当前所使用的交互式 Shell 名称相吻合。

#46506

⚡4⏳3

针对内核函数 do_unlinkat 编写两个版本的挂载探针，分别采用 BPF_KPROBE 宏与 BPF_PROG（fentry）宏实现，两者均输出目录文件描述符 dfd 以及待删除的目标文件名。具体要求如下：

• kprobe 版本使用 BPF_CORE_READ 安全读取 name->name，fentry 版本则通过原生指针直接解引用 name->name；
• 分别编译两个版本，提取 clang -S 汇编输出中负责参数提取与成员读取的核心指令片段，结合调用约定阐述 r1 + 112、r1 + 104 与 r1 + 0、r1 + 8 两套偏移量的物理来历；
• 分析说明为何 fentry 版本在编译时无须指定 -D__TARGET_ARCH_x86 宏，以及 kprobe 版本若省略该宏会导致怎样的编译期后果。

7.3 综合与挑战

#46507

⚡5⏳4

编写一个用户态探测工具 helper_probe，调用 libbpf 提供的 libbpf_probe_bpf_helper() 接口，用于自动化查询特定程序类型是否支持调用指定的辅助函数。具体实现要求如下：

• 命令行接收程序类型名称与辅助函数编号作为输入参数，例如执行 ./helper_probe tracepoint 113；
• 在代码内部维护一张从程序类型字符串到 enum bpf_prog_type 枚举值的映射表，至少覆盖 tracepoint、kprobe、xdp 与 cgroup_skb 四种常见类型；
• 针对编号 112 至 115、177 以及 bpf_get_current_task_btf 这一组辅助函数，在终端渲染输出一张二维兼容性矩阵表（以程序类型为行、辅助函数为列，单元格内标明可用性状态）；
• 阐述该编程接口与 bpftool feature probe 命令在底层实现机制上的内在联系，并说明运行该探测工具所需的系统权限要求。

若当前实验环境中未安装支持该接口的 libbpf 库，也可直接基于底层 bpf() 系统调用构造最小测试指令集完成探测，但需在文档中阐明探测逻辑具体触发了 BPF_PROG_LOAD 验证流程中的哪一个检查环节。

#46508

⚡5⏳4

基于内核 kfunc bpf_task_from_pid 编写一个状态查询探针：将待观测的目标 PID 定义为 const volatile 全局对象（由用户态加载器在 load 阶段前动态注入），每当指定的 tracepoint 事件触发时，在探针中根据该 PID 查找任务控制块，打印目标进程的 comm 名称及其父进程的 tgid。要求完成以下分析与验证：

• 结合验证器的引用追踪机制，解释为何在探针退出前必须成对调用 bpf_task_release，并实际验证遗漏该调用时内核验证器给出的拒绝日志；
• 使用 readelf -r 检查编译后的目标文件，确认函数调用点生成的是 R_BPF_64_32 符号重定位项；
• 执行 bpftool btf dump file /sys/kernel/btf/vmlinux format raw | grep bpf_task_from_pid 或直接检索 vmlinux.h，核实当前内核是否导出了该 kfunc 的原型声明，并讨论当目标内核缺失该符号时程序的加载表现。

#46509

⚡7⏳4选做

围绕“提取被观测操作的目标文件名”这一相同业务诉求，分别基于 tracepoint、kprobe 与 fentry 三种上下文模型各实现一份探针程序：

• tracepoint 版本挂载于 sched_process_exec，解析上下文中的 __data_loc_filename 动态定位字段；
• kprobe 版本挂载于 do_unlinkat，借助 BPF_CORE_READ 跨指针读取路径；
• fentry 版本挂载于 do_unlinkat，直接对带类型的函数参数执行原生解引用。

三份探针需复用同一套日志格式化与栈缓冲区逻辑（可将 bpf_printk 打印逻辑封装在公共头文件的 static __always_inline 内联函数中，注意统筹不同上下文中字符串地址的提取方式）。完成编码后，请整理出一份对比分析表，逐项归纳三种实现方案的以下技术特征：

• 上下文指针 ctx 的具体 C 类型及其内核数据来源；
• 提取函数参数所需的辅助宏与架构编译选项；
• 读取目标字符串所调用的辅助函数种类与调用次数；
• 编译生成的底层指令调用序列（提取自 clang -S 输出）。

最后结合内核跟踪子系统的设计原理，阐述为何 __data_loc 这种偏移与长度拼接编码仅存在于 tracepoint 上下文记录中，而在 kprobe 与 fentry 探针中均无需引入此类机制。

8. 参考资料

• bpf-helpers(7) 手册页：详述了辅助函数的程序类型白名单机制、五参数寄存器传递上限、各函数的运行时语义以及 GPL 许可证约束标记。https://man7.org/linux/man-pages/man7/bpf-helpers.7.html
• libbpf 核心头文件（bpf_helper_defs.h、bpf_helpers.h、bpf_tracing.h、bpf_core_read.h）：展示了基于静态编号的函数指针声明技巧、bpf_printk 在 bpf_trace_printk 与 bpf_trace_vprintk 之间的自动分发逻辑，以及 BPF_KPROBE 与 BPF_PROG 宏的预处理展开实现。https://github.com/libbpf/libbpf
• Linux 内核官方文档 BPF kfuncs：阐述了 kfunc 作为内核内部通信接口的设计定位及其不承诺跨版本 ABI 稳定性的演进原则。https://docs.kernel.org/bpf/kfuncs.html
• Linux 内核官方文档 Event Tracing：介绍了 tracefs 中事件 format 文件的字段布局规范及典型调度事件的记录样例。https://docs.kernel.org/trace/events.html
• Linux 内核源码 include/trace/stages/stage1_struct_define.h 与 include/trace/trace_events.h：包含 __dynamic_array 宏展开为 u32 __data_loc_<item> 字段的底层定义及高低 16 位编码规则的源码注释。https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/include/trace/stages/stage1_struct_define.h
• Linux 内核源码 kernel/trace/trace_events_filter.c：展示了 filter_pred_strloc 函数通过 str_item & 0xffff 提取相对偏移、通过 str_item >> 16 提取字节长度的具体实现。https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/kernel/trace/trace_events_filter.c
• Linux 内核源码 kernel/trace/bpf_trace.c、kernel/bpf/helpers.c 与 kernel/bpf/verifier.c：涵盖了辅助函数的 gpl_only 属性定义、bpf_task_from_pid 的 KF_ACQUIRE | KF_RET_NULL 引用标记，以及验证器针对 invalid mem access 与 GPL-restricted 违规行为的检查逻辑。https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/kernel/bpf/verifier.c
• bpftool 官方文档 bpftool-feature：说明了 feature probe、list_builtins 以及 unprivileged、full 等探测模式的使用方法。https://github.com/libbpf/bpftool/blob/main/docs/bpftool-feature.rst
• libbpf-bootstrap 示例工程的 kprobe 与 fentry 章节：提供了 do_unlinkat 探针的两种挂载实现与 trace_pipe 观测方法，本文中的对比示例参考了该工程的设计思路。https://github.com/libbpf/libbpf-bootstrap
• Andrii Nakryiko，BPF CO-RE reference guide：深入解析了 BPF_CORE_READ 宏的嵌套展开机制及其与原生指针解引用的底层差异。https://nakryiko.com/posts/bpf-core-reference-guide/
• Liz Rice，Learning eBPF（ISBN 978-1-098-13512-6），第 4、5 章：系统讨论了辅助函数、执行上下文与 BPF 程序类型之间的对应关系。
• 本节展示的十六进制转储、汇编指令与 readelf 输出均在 Debian 13（Linux 内核 6.12）环境下基于 vmlinux.h 与 libbpf 1.5 头文件编译生成；bpftool feature list_builtins、bpftool gen skeleton 及 id_demo 的运行结果均来自同一实测环境。