第3章 BPF 技术原理

从字节码到 JIT

章节导读

前两章我们建立了 BPF 的宏观认知和追踪机制的背景，现在到了打开引擎盖的时刻。本章深入 BPF 虚拟机本身：它的指令集长什么样、验证器如何证明程序安全、JIT 如何把字节码变成机器码、map 如何在内核态和用户态之间传递数据、辅助函数如何安全地暴露内核能力、以及 CO-RE 如何解决困扰 BPF 生态多年的可移植性难题。这些内容看似底层，实则是你从"工具使用者"进阶为"工具开发者"的必经之路——第 12 章写自定义工具时，验证器的每一条拒绝信息、map 的每一次选型、辅助函数的每一个限制，都来自本章的知识。

先回答一个根本问题：为什么内核需要一个虚拟机？直接加载内核模块不是更简单吗？答案在于信任模型。内核模块以 ring 0 权限运行，一个 bug 就是整机崩溃，所以生产环境对模块的态度是"默认不信任"。而 BPF 的设计目标是让不受信任的用户（相对于内核而言）提交代码到内核执行，且保证这段代码绝对无害。实现这个保证的技术路径就是"字节码 + 验证器"：用户提交的不是机器码而是受限指令集的字节码，验证器对字节码做穷尽的静态分析，证明其安全性后才翻译执行。这个架构与 Java 虚拟机、WebAssembly 的思路一脉相承，但 BPF 验证器的保证更强——它不仅防恶意，还防 bug：任何可能越界、死循环、访问未初始化内存的程序都会被拒绝，无论提交者是否有意。

BPF 虚拟机的设计处处体现"为内核环境定制"的哲学。11 个 64 位寄存器直接映射到 x86_64 的物理寄存器，使 JIT 翻译几乎是一对一的寄存器分配；指令集只有寥寥几类（算术、跳转、加载、存储、函数调用），足够表达追踪逻辑又小到验证器可以穷尽分析；512 字节的栈空间强制程序保持简单；没有浮点运算（早期内核态避免 FPU 状态保存的开销）；内存访问全部经过边界检查。这些限制换来了两个关键属性：验证的可行性和执行的确定性。

验证器是 BPF 安全模型的核心，也是初学者最大的痛点。它的工作分为几个阶段：首先构建控制流图（CFG），拒绝包含不可达代码和非法跳转的程序；然后做深度优先的路径模拟执行，跟踪每个寄存器的类型和取值范围（值域追踪，value tracking），任何一条路径上出现越界访问、类型错误、未初始化读取都会导致拒绝；同时检查程序复杂度（指令数、路径数、状态数）不超过上限。验证器的错误信息以晦涩著称——它会打印出完整的指令序列和寄存器状态，需要经验才能定位问题。本章会解读几个典型的验证器拒绝案例，掌握"读懂验证器日志"这项 BPF 开发的核心技能。

通过验证后，JIT 编译器把 BPF 字节码翻译成本地机器码。这不是可选的优化而是安全模型的一部分：解释执行字节码需要复杂的解释器（本身是攻击面），而 JIT 后的原生代码执行路径简单、速度快（接近手写内核 C 代码）、且可以在执行前做额外的硬件保护（如 BPF 内存的只读保护）。现代内核默认开启 JIT（net.core.bpf_jit_enable=1），一次 JIT 编译耗时微秒到毫秒级。

BPF maps 是内核态与用户态、以及多个 BPF 程序之间共享数据的机制。map 类型从最初的哈希表和数组发展出十几种：perf event array（高速事件流输出）、ring buffer（5.8+，比 perf buffer 更高效且不丢序）、LRU 哈希（自动淘汰防内存耗尽）、per-CPU 变体（无锁高性能）、队列、栈、trie 等。选择正确的 map 类型直接决定工具的性能和正确性——例如高频计数必须用 per-CPU 哈希避免锁竞争，延迟直方图用数组按对数分桶。

辅助函数（helper functions）是 BPF 程序调用内核能力的唯一通道。BPF 程序不能调用任意内核函数（那会破坏安全模型），只能调用内核显式暴露的白名单函数：bpf_get_current_pid_tgid（获取当前进程/线程 ID）、bpf_probe_read（安全读取任意内核内存）、bpf_ktime_get_ns（单调时钟）、bpf_map_lookup_elem（查 map）、bpf_trace_printk（调试输出）等，如今已有两百多个。每种程序类型能调用的辅助函数集合不同，验证器会检查。

最后是 CO-RE——BPF 可移植性的终极答案。传统 BPF 程序直接引用内核数据结构（如 struct task_struct 的字段偏移），而内核结构体的布局随版本变化，导致 BPF 程序必须针对每个内核版本重新编译（BCC 的运行时编译就是为此而生，代价是目标机器需要完整的编译工具链）。CO-RE 的方案：编译时把对内核结构的字段访问记录为"重定位信息"，配合内核暴露的 BTF（BPF Type Format，内核数据结构的完整类型信息），libbpf 在加载时按当前内核的实际布局修正偏移——实现"一次编译，到处运行"。5.2+ 内核自带 BTF（CONFIG_DEBUG_INFO_BTF），如今主流发行版全部支持，CO-RE 已成为新 BPF 项目的默认选择。

本章内容密度较高，建议配合实验动手验证：写几个会被验证器拒绝的程序观察报错、用 bpftool 查看 JIT 后的机器码、对比不同 map 类型的性能。理解了本章，后面所有工具章节的"工作原理"部分都将一目了然。

核心概念

BPF 虚拟机
验证器
JIT
BPF maps
辅助函数
CO-RE
BTF
程序类型

要点精析

【BPF 虚拟机：寄存器与指令集】eBPF 虚拟机有 11 个 64 位寄存器 R0-R10：R0 是返回值寄存器；R1-R5 是函数参数寄存器（BPF 程序被调用时，R1 携带上下文指针，如 kprobe 场景下指向 pt_regs）；R6-R9 是 callee-saved 寄存器，可在辅助函数调用间保持值；R10 是只读栈指针，栈空间固定 512 字节。指令是固定 8 字节编码：操作码(8bit) + 目标寄存器(4bit) + 源寄存器(4bit) + 偏移(16bit) + 立即数(32bit)。指令类别包括：ALU/ALU64（加减乘除与或异或移位）、JMP（条件/无条件跳转，5.3+ 支持部分尾调用式跳转）、LD/LDX（加载，含特殊的 LDX 变体读取上下文）、ST/STX（存储到栈或 map）、CALL（调用辅助函数或尾调用）、EXIT。设计上每个寄存器直接对应 x86_64 的一个物理寄存器（R10 对应 rbp），JIT 翻译近乎直译。理解指令集的实际意义：验证器错误信息以指令序号报告问题，你需要能对照汇编定位出错语句；bpftool prog dump 可以反汇编已加载的程序。

【BPF 程序类型：挂载点决定能力】BPF 程序不是通用的——加载时必须声明类型（enum bpf_prog_type），类型决定了：能挂载到哪里、上下文中能读到什么、能调用哪些辅助函数。与性能追踪相关的主要类型：BPF_PROG_TYPE_KPROBE（挂 kprobe/uprobe/perf_event，上下文是 pt_regs，最通用的追踪类型）、BPF_PROG_TYPE_TRACEPOINT（挂 tracepoint，上下文是 tracepoint 参数结构）、BPF_PROG_TYPE_RAW_TRACEPOINT（5.2+，直接拿原始参数，省去 tracepoint 参数封装的开销）、BPF_PROG_TYPE_PERF_EVENT（挂 PMC/定时器采样）。网络类型：XDP（网卡驱动层，上下文是 xdp_md，每包执行）、SK_SKB、CGROUP_SKB 等。安全类型：LSM（5.7+，挂内核安全钩子）。seccomp 用的 cBPF 是独立的老类型。书中强调：性能工具 99% 使用 KPROBE 和 TRACEPOINT 两种类型；bpftrace 和 BCC 把类型选择自动化了——你写 kprobe:xxx 它就加载 KPROBE 类型程序。程序类型的权限模型也在演进：非 root 用户能加载的类型有限（unprivileged BPF 因安全漏洞在多数发行版被禁用）。

【验证器：安全性的数学保证】验证器（kernel/bpf/verifier.c，数万行代码）在程序加载时执行，流程：(1) DAG 检查——构建控制流图，拒绝循环（5.3 前）和不可达代码；(2) 路径模拟——深度优先遍历所有执行路径，为每个路径维护寄存器状态（类型 + 值域）和栈状态，任何状态非法立即拒绝；(3) 状态剪枝——路径爆炸时用状态等价性剪枝（当前状态若被之前验证过的状态"包含"则跳过），这是验证器能处理复杂程序的关键；(4) 资源限制——指令总数（100 万）、单路径指令数、验证状态数、map 深度嵌套（如 map-in-map）等。寄存器类型系统很精细：NOT_INIT（未初始化）、SCALAR_VALUE（标量，带值域 min/max/var_off）、PTR_TO_MAP_VALUE（map 值指针，带边界）、PTR_TO_CTX（上下文指针）、PTR_TO_STACK 等。典型拒绝原因：读取未初始化寄存器、map 值指针未判空就解引用、栈越界（超过 512 字节或越过 R10）、变量偏移访问 map 值时值域过宽无法证明安全、程序过长。验证器的严格性随内核版本演进：新内核更聪明（能证明更多程序安全），老内核会拒绝新内核接受的程序——这是 BPF 程序"向上兼容容易、向下兼容难"的原因。

【读懂验证器错误：BPF 开发的核心技能】验证器拒绝程序时会输出详细日志（BCC 中直接打印，libbpf 需设置 log_level）。日志格式：每行是指令序号 + 反汇编 + 当前寄存器状态。解读方法：从最后一行错误消息（如 "invalid mem access 'inv'" 或 "R1 !read_ok"）向上回溯，找到出问题的指令序号，对照你的 C 源码定位。三个最常见错误模式：(1) map lookup 未判空——bpf_map_lookup_elem 返回的指针可能为 NULL，必须 if (val == NULL) return 0; 之后才能解引用，忘记判空是新手第一错；(2) 变长访问越界——用变量作偏移读取上下文或 map 值时，验证器要求能证明偏移在界内，通常需要显式的 if (offset < MAX) 检查，且检查后不能再修改 offset；(3) 未初始化栈——声明了局部变量但在某条路径上未赋值就使用。调试技巧：用 bpf_trace_printk 打印中间状态（它会出现在 /sys/kernel/debug/tracing/trace_pipe）；二分法注释代码缩小范围；把复杂逻辑拆成多个小函数（5.x 内核支持 BPF 到 BPF 函数调用，每个函数独立验证）。

【JIT 编译：字节码到机器码】验证通过后，JIT 把 BPF 字节码翻译成本地指令。x86_64 JIT（arch/x86/net/bpf_jit_comp.c）的翻译近乎直译：BPF 寄存器映射到物理寄存器（R0→rax, R1→rdi, ..., R10→rbp），ALU64 指令对应 x86 的 64 位运算指令，辅助函数调用翻译成 call 指令。JIT 还做优化：常量折叠、跳转目标直接编码、map 访问的内联优化（如数组 map 的查找直接翻译成基址+偏移计算）。控制开关：net.core.bpf_jit_enable=1（默认开启，静默）、=2（开启并把 JIT 结果打印到内核日志，可用 bpf_jit_disasm 工具反汇编对照）。JIT 的安全演进值得了解：Spectre 漏洞后，JIT 加入了常量致盲（constant blinding，把立即数替换为随机值的运算，防止 JIT 喷射攻击）、BPF 内存只读保护等。性能数据：JIT 后的 BPF 程序执行速度约为解释执行的 10-100 倍，与等价的内核 C 代码差距在 10% 以内。书中建议生产环境永远开启 JIT——现代发行版默认如此，但某些容器基础镜像的内核参数可能关闭了它，部署前检查。

【BPF maps：内核态数据结构全解】map 是 BPF 程序与外界交换数据的唯一持久通道。核心类型：(1) HASH / PERCPU_HASH——任意键值对，PERCPU 变体每 CPU 一份副本，更新无锁，读取时用户态需聚合各 CPU 值，高频计数首选；(2) ARRAY / PERCPU_ARRAY——整数索引，查找 O(1) 且验证器友好（值指针永远有效无需判空），预分配内存，直方图（按对数桶索引）首选；(3) PERF_EVENT_ARRAY——每 CPU 一个 perf ring buffer，BPF 程序用 bpf_perf_event_output 把事件发给用户态，是 BCC 工具的标准输出通道，缺点是按 CPU 分散、用户态需轮询多个 buffer、可能乱序；(4) RINGBUF（5.8+）——单一共享环形缓冲，多生产者单消费者，支持事件间内存共享和自适应轮询，比 perf buffer 内存效率高一个量级且保序，新工具首选；(5) LRU_HASH——容量满时自动淘汰最久未用条目，防止键空间爆炸（如以 PID 为键但进程疯狂创建的场景）；(6) QUEUE/STACK（4.20+）——无键的 FIFO/LIFO；(7) ARRAY_OF_MAPS/HASH_OF_MAPS——map 嵌套，实现按容器/租户分桶。map 的通用属性：max_entries（容量上限，必须预设）、key_size/value_size。选型口诀：计数聚合用 PERCPU_HASH，直方图用 ARRAY，事件流输出用 RINGBUF（老内核 PERF_EVENT_ARRAY），有界缓存用 LRU_HASH。

【辅助函数：BPF 触碰内核的手】BPF 程序通过辅助函数访问内核能力，原型统一为 u64 fn(u64 r1..r5)。追踪场景最常用的：bpf_get_current_pid_tgid()——返回 u64，高 32 位是 PID（内核视角的 tgid，即用户态的进程 ID），低 32 位是 TID（内核视角的 pid，即线程 ID），注意这个"反直觉"的命名是历史遗留；bpf_get_current_comm()——当前进程名（16 字节）；bpf_ktime_get_ns()——单调时钟纳秒（延迟测量的基准，注意不是墙上时间，跨睡眠单调递增）；bpf_probe_read()/bpf_probe_read_kernel()/bpf_probe_read_user()——安全读取任意内核/用户内存，读取失败返回错误而不崩溃（5.5 起拆分为 kernel/user 两个版本，与 SMAP/PAN 硬件特性配合）；bpf_perf_event_output()——向 perf buffer 发事件；bpf_get_current_stack_trace()——抓取当前调用栈存入 map（火焰图的基础）；bpf_override_return()——修改被 kprobe 函数的返回值并跳过执行（需内核开启 CONFIG_BPF_KPROBE_OVERRIDE，仅限白名单函数，故障注入测试用）；bpf_send_signal()（5.3+）——向当前进程发信号。每种程序类型可用的辅助函数集合由验证器强制检查，bpftrace 的内置函数（如 pid、comm、ustack）就是这些辅助函数的封装。

【上下文与参数读取：pt_regs 的陷阱】kprobe 类型 BPF 程序的上下文 R1 指向 pt_regs——被挂载时刻的 CPU 寄存器快照。读取函数参数就是读 pt_regs 的相应寄存器：x86_64 内核函数调用约定中前 6 个参数在 rdi/rsi/rdx/rcx/r8/r9（bpftrace 的 arg0-arg5 即对应这些）。但有几个大坑：(1) 架构差异——ARM64 参数在 x0-x7，脚本跨架构移植时 arg 映射不同，bpftrace 帮你屏蔽了这层；(2) 寄存器复用——函数执行过程中寄存器会被改写，kretprobe 时 arg0 已不是原参数值，这就是"入口存 map、出口取用"模式的根本原因；(3) 用户态参数——系统调用 tracepoint 的参数指针指向用户内存，必须用 bpf_probe_read_user 读取（bpftrace 的 str() 自动处理），直接用内核读法会失败；(4) 内联与优化——编译器可能把参数优化进其他寄存器或栈，kprobe 拿到的 pt_regs 未必符合源码签名，挂载前用 crash 或 drgn 验证。BCC 的 PT_REGS_PARM1(ctx) 等宏封装了架构差异；libbpf 的 BPF_KPROBE 宏自动生成参数解包代码，是现代写法。

【BTF 与 CO-RE：可移植性革命】BTF（BPF Type Format）是内核数据结构的紧凑类型信息（DWARF 的精简版），内核开启 CONFIG_DEBUG_INFO_BTF 后在 /sys/kernel/btf/vmlinux 暴露全部内核类型（数百 KB）。CO-RE 的工作流：开发者写 BPF C 代码时用 BPF_CORE_READ(task, mm, start_code) 这样的宏访问内核结构字段，Clang 编译时生成字节码 + BPF 重定位记录（"这里要读 task_struct 的 mm 字段再读 mm_struct 的 start_code 字段"）；加载时 libbpf 读取当前内核的 BTF，查出这些字段在本内核的实际偏移，重写指令中的偏移量。于是同一个 .o 文件可以在 5.4 和 6.6 内核上运行——即使字段偏移完全不同。CO-RE 还带来：字段存在性检查（bpf_core_field_exists，写"新内核走新路径、老内核走老路径"的兼容逻辑）、类型大小查询、枚举值查询。生态影响是决定性的：BCC 需要目标机器装 LLVM（约 200MB、启动秒级），CO-RE+libbpf 只需一个静态链接的二进制（启动毫秒级），这使得 BPF 工具可以像普通程序一样打包分发。bpftrace 也在 0.16+ 支持了基于 BTF 的运行。检查你的环境：ls /sys/kernel/btf/vmlinux 存在即可用 CO-RE。

【BPF 程序生命周期：从加载到分离】完整流程：(1) 编译——Clang 把受限 C 编译成 BPF 字节码 ELF 对象（含 map 定义、程序段、BTF、重定位信息）；(2) 加载——用户态调用 bpf(BPF_PROG_LOAD) 提交字节码，内核验证 + JIT，返回程序 fd；(3) map 创建——bpf(BPF_MAP_CREATE) 创建 map，把 map fd 重写进程序的指令（或 CO-RE 重定位）；(4) 附加——按类型 attach：kprobe 通过 perf_event_open + ioctl 关联，tracepoint 同理，XDP 通过网卡 netlink 命令；(5) 运行——事件触发程序执行；(6) 分离与卸载——关闭 fd、解除 attach，引用计数归零后内核释放程序内存。关键机制是"一切皆 fd + 引用计数"：程序和 map 的生命周期由 fd 引用管理，用户态进程退出后，若程序仍被挂载点引用则继续运行（这就是为什么 bpftrace 被 kill -9 后探针可能残留，需要检查 /sys/kernel/debug/tracing/kprobe_events）；pinned 到 bpffs（/sys/fs/bpf/）的 map/程序可以跨进程共享和持久化，这是生产级 BPF 应用（如 Cilium agent 重启不中断数据面）的基础。bpftool 是观察生命周期的窗口：bpftool prog list 显示所有已加载程序（类型、指令数、内存占用、tag），bpftool map list 显示所有 map。

【BPF 的性能边界：什么时候 BPF 本身成为瓶颈】BPF 程序单次执行极快（纳秒到微秒），但工程实践中仍有性能边界：(1) 事件频率——每次触发的总成本 = 挂载点开销（kprobe 约 1-2μs，tracepoint 约 0.1-0.5μs）+ BPF 程序执行 + map 操作，每秒百万级事件时即使每事件 1μs 也消耗一个 CPU 核，对 malloc、页错误级别的超高频事件必须过滤或采样；(2) map 竞争——普通 HASH 的更新有桶级自旋锁，多核高频更新同键会锁竞争，PERCPU 变体是标准解法，代价是读取时聚合和内存 ×CPU 数；(3) 输出通道——perf buffer 每事件约 0.5-1μs 且用户态轮询有延迟，ringbuf 更优，但每秒十万级事件输出仍会压垮用户态处理，正确做法是内核态聚合成直方图/计数，只输出统计；(4) 程序复杂度——验证器限制下，复杂逻辑（长循环、大栈结构）写不出来，需要拆分为多个程序或移到用户态；(5) 尾调用——bpf_tail_call 可以链式调用多个 BPF 程序突破单程序复杂度限制，但有 33 层深度限制和额外的栈切换开销。书中的经验法则：BPF 程序应该只做"过滤 + 提取 + 聚合"，把解释和展示留给用户态——这既是性能要求也是架构美学。

代码示例

/* 示例1：观察已加载的 BPF 程序与 map */
sudo bpftool prog list
/* 输出示例：
123: kprobe  name some_prog  tag abc123  gpl
     loaded_at 2024-01-01T10:00:00  uid 0
     xlated 456B  jited 289B  memlock 4096B  map_ids 45
*/
sudo bpftool map dump id 45
sudo bpftool prog dump xlated id 123   /* 查看 BPF 字节码 */
sudo bpftool prog dump jited id 123    /* 查看 JIT 后的机器码 */

bpftool 是 BPF 的"ps 命令"，内核自带（linux-tools 或 bpftool 包）。prog list 显示所有已加载程序：类型（kprobe/tracepoint/xdp...）、名字（C 函数名，最长 15 字符）、tag（字节码哈希，用于比对）、xlated 大小（验证器处理后的字节码）、jited 大小（机器码）、关联的 map_ids。dump xlated 输出验证器重写后的 BPF 汇编，dump jited 输出 JIT 机器码——对照阅读这两者能直观理解"字节码到机器码"的翻译过程。map dump 以 JSON 输出 map 内容，是检查内核态聚合结果的直接手段（bpftrace 退出前你也可以用 Ctrl-C 触发输出，但 bpftool 可以在程序运行中随时窥视）。实战用途：怀疑某个监控 agent 挂了 BPF 程序拖慢系统？bpftool prog list 一目了然。bpftrace 脚本意外退出后探针残留？prog list 找到 id 后 bpftool prog pin/show 排查。建议把 bpftool prog list | wc -l 加入你的系统巡检清单。

/* 示例2：一个典型的验证器拒绝——map 查找未判空 */
bpftrace -e 'kprobe:vfs_read { $val = @counts[comm]; printf("%d\n", $val); }' 2>&1 | head
/* 手写 BCC C 程序时的等价错误：
int kprobe__vfs_read(struct pt_regs *ctx) {
    u64 *val = bpf_map_lookup_elem(&counts, &key);
    u64 v = *val;            /* 错误：val 可能为 NULL */
    return 0;
}
验证器输出： R0 invalid mem access 'inv' ...
*/

map 查找未判空是 BPF 新手的第一课。bpf_map_lookup_elem 在键不存在时返回 NULL，直接解引用会导致内核空指针访问——验证器通过类型系统（返回值标记为 PTR_TO_MAP_VALUE_OR_NULL）强制你判空。正确写法：if (!val) return 0; 或使用 map 的 update 语义先确保键存在。bpftrace 中 @map[key] 的读取自动处理了这个问题（不存在的键返回 0），所以这个错误主要出现在手写 BCC/libbpf C 程序时。验证器日志的解读方法：找到 "invalid mem access" 行，R0 是出问题的寄存器，'inv' 表示它当前是"无效标量"类型（NULL 指针被归入此类）；向上回溯指令序号找到对应的 C 语句。BCC 会把验证器完整日志打印出来（几十到几百行），别慌，直接看最后 10 行。这个例子也解释了为什么 ARRAY 类型 map 对验证器更友好：数组查找永远返回有效指针（索引在界内时），省去判空和相应的路径爆炸。

/* 示例3：BPF C 程序完整结构——libbpf 风格骨架 */
#include "vmlinux.h"              /* CO-RE：由 BTF 生成的全内核类型头 */
#include <bpf/bpf_helpers.h>
#include <bpf/bpf_tracing.h>
#include <bpf/bpf_core_read.h>

struct {                            /* map 定义：现代 BTF 风格 */
    __uint(type, BPF_MAP_TYPE_HASH);
    __uint(max_entries, 10240);
    __type(key, u32);
    __type(value, u64);
} start SEC(".maps");

SEC("kprobe/vfs_read")              /* SEC 宏声明程序类型和挂载点 */
int BPF_KPROBE(trace_read, struct file *file) {
    u32 tid = bpf_get_current_pid_tgid();
    u64 ts = bpf_ktime_get_ns();
    bpf_map_update_elem(&start, &tid, &ts, BPF_ANY);
    return 0;
}
char LICENSE[] SEC("license") = "GPL";   /* 非 GPL 无法用部分辅助函数 */

这是现代 libbpf+CO-RE 风格 BPF 程序的标准骨架，每个部分都值得 memorize：vmlinux.h 由 bpftool btf dump file /sys/kernel/btf/vmlinux format c 生成，包含当前内核全部类型定义（替代了手工维护的头文件）；SEC(".maps") 的 BTF 风格 map 定义取代了老的 bpf_map_def 结构；SEC("kprobe/vfs_read") 告诉 libbpf 加载后自动 attach 到哪里；BPF_KPROBE 宏自动从 pt_regs 解包参数（处理架构差异）；LICENSE 段必须声明 GPL（或兼容），否则验证器会拒绝调用 bpf_probe_read 等"GPL-only"辅助函数——这是内核模块许可模型在 BPF 中的延续。编译命令：clang -O2 -g -target bpf -c prog.bpf.c -o prog.bpf.o，然后 libbpf 的 skeleton 机制（bpftool gen skeleton）生成用户态加载代码。对比 BCC 风格（C 代码嵌在 Python 字符串里、运行时编译），libbpf 风格预编译、启动快、可分发，是 2020 年后新项目的标准选择。bpftrace 则适合一次性脚本——三种工具对应三种工程场景。

/* 示例4：per-CPU map 与直方图的数组实现 */
bpftrace -e 'kprobe:tcp_sendmsg { @bytes[cpu] = sum(arg2); }'
/* bpftrace 的 @ 聚合默认就是 per-CPU 的 */
/* BCC C 中手写对数直方图的核心逻辑： */
u64 delta = bpf_ktime_get_ns() - ts;
u32 index = 0;
if (delta > 0) {
    /* 计算 log2(delta) 作为桶索引 */
    while (delta >>= 1) index++;
}
if (index < 64) {
    u64 *count = bpf_map_lookup_elem(&hist, &index);
    if (count) __sync_fetch_and_add(count, 1);
}

延迟直方图是 BPF 工具的标志性输出，其内核实现有两个关键设计。第一，桶索引用 log2：64 个桶覆盖从 1ns 到 2^64ns 的全部延迟范围，内存只需 64×8=512 字节的 ARRAY map，且任何延迟值都能 O(1) 定位桶——这就是 biolatency 等工具直方图呈 2 的幂次分桶的原因。bpftrace 的 hist() 内置了这个逻辑（还有 lhist() 提供线性分桶）。第二，计数更新用原子操作或 per-CPU map：多 CPU 同时更新同一个桶时，__sync_fetch_and_add（编译成 BPF 的原子加指令，5.12+ 原生支持，之前用 per-CPU map + 锁）避免计数丢失。bpftrace 中所有 @ 聚合变量默认按 CPU 分离存储、输出时合并，你不用操心这些细节——但手写 BCC/libbpf 工具时必须显式选择 PERCPU_ARRAY（读取时用户态把各 CPU 值相加）或普通 ARRAY+原子加。per-CPU 方案的代价：内存 ×CPU 数（128 核机器上 10240 条目的 per-CPU 哈希要几十 MB），以及"读取瞬间各 CPU 值非同一时刻快照"的轻微不一致——对统计场景完全可接受。

/* 示例5：用 bpf_trace_printk 调试 + 查看 trace_pipe */
bpftrace -e 'kprobe:vfs_read { printf("read by %s (pid %d) size %d\n", comm, pid, arg2); }' 
/* 底层等价的 C 代码：
char fmt[] = "read by %s size %d\n";
bpf_trace_printk(fmt, sizeof(fmt), comm_buf, size);
*/
sudo cat /sys/kernel/debug/tracing/trace_pipe   /* printk 输出去向 */

bpf_trace_printk 是 BPF 的 printf 调试法：输出写入内核的 trace_pipe（一个全局的追踪日志缓冲），cat 即可实时查看。bpftrace 的 printf 底层就是它（新版本可切换 ringbuf 输出）。必须知道的限制：(1) 它走内核 trace 缓冲，有全局锁，每次调用约几微秒——比 map 聚合慢一个数量级，高频事件中用它会显著扭曲被测系统（观察者效应），只适合调试和低频事件；(2) 格式串限制——最多 3 个参数（老内核），字符串必须先 bpf_probe_read_str 读到栈上的定长数组；(3) 输出可能被丢弃——trace 缓冲满时覆盖旧记录。调试工作流：开发时大量 printf 观察变量值和执行路径，确认逻辑正确后全部替换为 map 聚合。C 语言 BPF 程序中 printf 不可用（没有标准库），bpf_trace_printk 是唯一选择；libbpf 项目通常用 bpf_printk 宏（bpf_helpers.h 提供）简化调用。trace_pipe 是流式的（读走即删），trace 文件则是快照式的，两者配合使用。

/* 示例6：检查 BTF 与 CO-RE 环境 */
ls -la /sys/kernel/btf/vmlinux
bpftool btf dump file /sys/kernel/btf/vmlinux format c | head -30
bpftool feature probe | grep -A3 btf
/* 生成 vmlinux.h 供 libbpf 项目使用： */
bpftool btf dump file /sys/kernel/btf/vmlinux format c > vmlinux.h
/* 检查内核结构字段是否存在（CO-RE 兼容编程）： */
if (bpf_core_field_exists(task->struct_field)) { /* 新内核路径 */ }

CO-RE 的前提是内核暴露 BTF。检查 /sys/kernel/btf/vmlinux 是否存在：存在则你的内核（5.2+ 且开启 CONFIG_DEBUG_INFO_BTF）支持 CO-RE；不存在则需要升级内核或自行用 pahole 从 vmlinux 的 DWARF 信息生成 BTF（老内核的曲折路径，主流发行版内核 5.4+ 都已内置）。bpftool btf dump 把二进制的 BTF 转成 C 头文件（vmlinux.h，通常 10-20 万行，包含内核所有结构体定义），这是 libbpf 项目的标准第一步——从此你的 BPF C 代码 include 这一个头文件就能引用任何内核类型，不再依赖系统安装的 kernel-headers（版本经常对不上，这是 BCC 时代的老大难）。bpf_core_field_exists 和 bpf_core_read 系列宏是 CO-RE 兼容编程的工具：字段在新内核才有？用 field_exists 分支处理。结构改名了？BPF_CORE_READ 的重定位会失败并在加载时报错，提示你用 bpf_core_type_exists 做版本适配。libbpf-bootstrap 仓库（github.com/libbpf/libbpf-bootstrap）提供了完整的 CO-RE 项目模板和 Makefile，是动手起步的最佳脚手架。

实验笔记

本实验深入 BPF 内部机制：观察验证器、解剖 JIT、操作 map、验证 CO-RE。预计耗时 3 小时。环境要求：内核 5.4+（CO-RE 实验需要 BTF），安装 bpftool、bpftrace、clang/llvm（10+）、libbpf-dev。

【实验一：BPF 程序普查与解剖】(1) 运行 sudo bpftool prog list 和 sudo bpftool map list，记录当前系统已加载的 BPF 程序和 map（即使你没运行任何工具，systemd、监控 agent 可能已经加载了一些——观察它们的类型和名字）。(2) 启动一个 bpftrace 脚本（如统计 vfs_read），在另一终端用 bpftool prog list 找到它，记录 xlated/jited 大小。(3) 用 bpftool prog dump xlated id N 查看 BPF 汇编，找到 map 查找和原子加的指令；再用 dump jited id N 查看对应机器码，对照理解 R0-R10 到物理寄存器的映射。(4) 思考：为什么 jited 大小通常小于 xlated 大小？（提示：BPF 指令定长 8 字节，x86 指令变长。）

【实验二：故意触发验证器拒绝】写三个会被拒绝的 BCC C 程序并记录验证器错误：(1) map lookup 后不判空直接解引用；(2) 读取未初始化的栈变量；(3) 写一个无界循环（在 5.3 以下内核会被拒，5.3+ 尝试写一个复杂度超限的循环——嵌套 10 层各迭代 100 万次）。对每个错误：记录验证器日志的最后 20 行，标注出错的指令序号，解释寄存器状态标记（如 'inv'、'map_value'）的含义，然后修复程序使其通过验证。这个实验的价值：验证器错误是 BPF 开发的日常，现在积累解读经验，将来调试真实工具时不至于手足无措。

【实验三：map 类型性能对比】用 BCC 或 libbpf 写两个版本的计数程序：版本 A 用 BPF_MAP_TYPE_HASH 统计每个进程的 vfs_read 次数；版本 B 用 BPF_MAP_TYPE_PERCPU_HASH 做同样的事。用 fio 或多进程 dd 制造每秒数万次读的负载，对比两个版本下负载程序的吞吐量差异，并用 bpftool map dump 观察两种 map 的内容结构差异（PERCPU 版本每个键有 num_cpu 个值）。记录结论：什么事件频率下 per-CPU 的收益开始显著？（提示：单核更新时两者差异很小，多核竞争同一键时普通 HASH 的自旋锁开销急剧上升。）

【实验四：CO-RE 实战】(1) 确认 /sys/kernel/btf/vmlinux 存在，生成 vmlinux.h。(2) 克隆 libbpf-bootstrap 仓库，编译运行 examples/c 下的最小 CO-RE 程序（如 uprobe 或 kprobe 示例），观察 skeleton 机制如何自动生成加载代码。(3) 写一个 CO-RE 程序读取 task_struct 的 comm 和 mm->start_code 字段（用 BPF_CORE_READ），验证输出。(4) 用 bpf_core_field_exists 写一个字段存在性分支，用 bpftool btf dump 查找一个你内核上存在的字段和一个不存在的字段（如某些新版本才有的 sched_ext 相关字段）分别测试两条路径。(5) 对比启动时间：同一个逻辑分别用 BCC（运行时编译）和 libbpf（预编译）实现，time 两者的启动耗时——典型结果是 BCC 需要 1-3 秒（调用 clang），libbpf 只需几十毫秒。

【实验五：辅助函数探索】写 bpftrace 脚本分别使用以下内置变量/函数并验证输出：pid 与 tid 的区别（启动一个多线程程序观察）、cpu、nsecs、kstack 与 ustack（对比内核栈和用户栈的输出格式）、cgroup。然后回答：bpf_get_current_pid_tgid() 返回的 u64 中，为什么"高 32 位是用户态的 PID"？（提示：内核的 task_struct->tgid 对应用户态进程 ID，task_struct->pid 对应线程 ID，命名历史与 Unix 进程模型演变有关。）

【实验报告要求】包含：实验一的 xlated/jited 对照片段；实验二每个验证器错误的日志摘录、原因分析、修复方法；实验三的吞吐对比表；实验四的 CO-RE 程序源码与运行输出；实验五的概念题答案。这些实验覆盖了 BPF 开发的完整技术栈，完成后你已具备阅读任何 BCC/bpftrace 工具源码的能力。