第2章：扩展版BPF——走进内核里的虚拟机

BPF程序的生命周期像一颗流星：在用户空间诞生，经过验证器的严酷审判，在内核中化为JIT后的机器码燃烧一瞬——但它的光芒足够照亮整个系统的暗角。

---

故事场景：一个"简单"工具的八小时长征

周五下午，小李接到了一个看似简单的任务：统计生产环境上每个MySQL查询的执行时间分布。

"不就是pt-query-digest嘛，"小李信心十足。但很快他发现，pt-query-digest需要抓包或慢日志，抓包对线上环境风险太大，慢日志又需要提前开启——而他需要从"现在"开始统计。

"老张，有什么好办法？"

老张正端着一杯放凉的咖啡："你想在不影响线上的前提下，精准测量每个query的时间？"

"对。"

"用BPF。attach到MySQL的dispatch_command函数，记录进入和退出的时间差。"

小李眼睛亮了。但当他真正动手时，才发现自己面对的是一整个陌生的世界：C语言写的BPF程序、LLVM编译成字节码、神秘的bpf()系统调用、验证器报错信息像天书、用户态的Python/BCC代码还要配合……

八小时后，当第一个直方图终于出现在屏幕上时，小李终于理解了老张那句轻描淡写的话背后，是多么精密的一套系统在支撑。

"每一个成功的BPF工具，"老张说，"背后都是一次从用户态到内核态的完整旅程。"

---

一、BPF架构：一台极简而严苛的虚拟机

1.1 寄存器模型：十个64位通用寄存器

eBPF采用了一个与x86_64极为相似的寄存器模型——这并非巧合，JIT编译正是利用这种相似性生成高效的机器码。

寄存器布局（64位）：
┌────────┬─────────────────────────────────────────┐
│ R0     │ 返回值 / 函数调用结果                    │
│ R1-R5  │ 函数参数 / 通用计算                      │
│ R6-R9  │ 被调函数保存的寄存器（Callee-saved）      │
│ R10    │ 只读帧指针（指向512字节栈的底部）         │
└────────┴─────────────────────────────────────────┘

这个寄存器约定是eBPF ABI（Application Binary Interface，应用二进制接口）的核心：

• R0是BPF程序返回给用户空间的值
• R1-R5用于向BPF辅助函数（helper function，辅助函数）传参
• R6-R9在函数调用中自动保留
• R10始终指向栈底，提供栈帧的锚点

// 一段极简的BPF指令（伪汇编）
// 计算 R1 = R2 + 10
BPF_MOV64_REG(BPF_REG_1, BPF_REG_2)   // R1 = R2
BPF_ALU64_IMM(BPF_ADD, BPF_REG_1, 10) // R1 += 10
BPF_EXIT_INSN()                        // return R0

1.2 指令集：一百条指令的子集宇宙

eBPF指令集被设计成"刚好够用"的极简集合——它没有高级语言的花哨特性，但覆盖了所有必要的计算和控制流。

指令类别	示例	用途
ALU	ADD, SUB, MUL, DIV, AND, OR, XOR, LSH, RSH	算术与位运算
ALU64	同上，但64位版本	64位算术（主用）
JMP	JA, JEQ, JGT, JGE, JSET, CALL, EXIT	跳转与函数调用
LD/LDX	LDXW, LDXH, LDXB, LDXD	从内存加载（32/16/8/64位）
ST/STX	STW, STH, STB, STD, STXW	向内存存储

graph LR
    subgraph "eBPF指令编码格式（64位）"
        A[Opcode 8位] --> B[目标寄存器 4位]
        B --> C[源寄存器 4位]
        C --> D[偏移量 16位]
        D --> E[立即数/值 32位]
    end
    F[一个64位指令] --> A

一个关键的设计决策是eBPF使用大端/小端自动感知：当BPF程序从网络包读取数据时，指令会自动处理字节序转换——这是网络过滤出身的基因遗传。

1.3 BPF Maps：程序与程序、内核与用户之间的桥梁

如果说寄存器和栈是BPF的"局部记忆"，那么BPF Maps就是它的"持久化存储"——一种特殊的键值数据结构，可以被BPF程序读写，也可以被用户空间程序访问。

// 定义一个BPF Map——在C中用宏声明
struct {
    __uint(type, BPF_MAP_TYPE_HASH);    // 类型：哈希表
    __uint(max_entries, 1024);         // 最多1024个键
    __type(key, u32);                   // 键：32位整数
    __type(value, u64);                 // 值：64位整数
} my_map SEC(".maps");

// BPF程序中读写Map
u32 pid = bpf_get_current_pid_tgid() >> 32;
u64 *val = bpf_map_lookup_elem(&my_map, &pid);
if (val) {
    (*val)++;
} else {
    u64 init = 1;
    bpf_map_update_elem(&my_map, &pid, &init, BPF_ANY);
}

graph LR
    subgraph "用户空间"
        A[Python/BCC程序] -->|bpf_map_lookup_elem| D[BPF Map]
        D -->|bpf_map_update_elem| A
    end
    subgraph "内核空间"
        B[BPF程序A] -->|bpf_map_lookup_elem| D
        C[BPF程序B] -->|bpf_map_update_elem| D
        D -->|共享数据| B
    end
    
    style D fill:#ffd93d,stroke:#333,stroke-width:2px

BPF Maps的类型丰富：

Map类型	用途
BPF_MAP_TYPE_HASH	通用键值存储
BPF_MAP_TYPE_ARRAY	固定大小数组，键为索引
BPF_MAP_TYPE_PERCPU_HASH	每个CPU独立一份，避免锁竞争
BPF_MAP_TYPE_STACK_TRACE	存储调用栈（配合stackid）
BPF_MAP_TYPE_LRU_HASH	自动淘汰最少使用的条目
BPF_MAP_TYPE_RINGBUF	单生产者多消费者环形缓冲区
BPF_MAP_TYPE_PROG_ARRAY	尾调用跳板（实现BPF程序跳转）

---

二、BPF程序生命周期：从C代码到内核中的流星

2.1 完整旅程：七步加载流程

sequenceDiagram
    participant U as 用户空间
    participant C as Clang/LLVM
    participant V as BPF验证器
    participant J as JIT编译器
    participant K as 内核
    participant E as 事件源

    U->>C: C代码 + bpf_helpers.h
    C->>C: 编译为eBPF字节码(.o文件)
    U->>K: bpf(BPF_PROG_LOAD, 字节码, ...)
    K->>V: 送入验证器
    alt 验证失败
        V->>U: -EPERM + 错误日志
    else 验证通过
        V->>J: 字节码 + 程序类型
        J->>J: 指令级翻译为机器码
        J->>K: 创建bpf_prog结构体
        K->>K: 插入全局prog数组
        K->>U: 返回文件描述符(fd)
        U->>K: bpf(BPF_RAW_TRACEPOINT_OPEN / kprobe...)
        K->>E: attach到事件源
        E->>K: 事件触发 → 执行BPF程序
    end

2.2 验证器：最严苛的安检

BPF验证器是整个BPF子系统中代码量最大、逻辑最复杂的部分。它的任务只有一个：证明这个程序不会伤害内核。

验证器的核心算法是有界符号执行：

# 验证器核心逻辑的抽象表达（伪代码）
def verify(program):
    states = [初始状态(R1=上下文指针, 其余=未初始化)]
    visited = set()
    
    while states:
        state = states.pop()
        insn = program[state.pc]
        
        # 复杂度上限：防止验证本身爆炸
        if state.complexity > MAX_COMPLEXITY:
            return REJECT("程序太复杂")
        
        # 状态剪枝：如果这个位置已经被验证过且当前状态更宽松
        if state in visited:
            continue
        visited.add(state)
        
        # 逐指令模拟执行，更新寄存器类型和范围
        new_states = simulate(insn, state)
        
        for ns in new_states:
            if ns.pc == len(program):  # 到达程序末尾
                if ns.returns_valid_value():
                    continue
                else:
                    return REJECT("返回值非法")
            else:
                states.append(ns)
    
    return ACCEPT

验证器的"严苛"体现在几个具体规则上：

1. 无循环：如果验证器检测到回边（back edge），程序会被拒绝。这就保证了终止性——BPF程序永远能在有限步内结束。
2. 边界检查：所有内存访问（无论是上下文、栈、Map还是包数据）都必须被证明在安全范围内。未证明安全的访问会被拒绝。
3. 未初始化寄存器不可读：一个寄存器在被赋值之前不能用于计算或条件跳转。
4. 类型安全：指针和整数不能混用。例如，你不能把一个表示偏移量的整数加到上下文指针上——必须是通过受控的方式解引用。
5. 辅助函数白名单：BPF程序只能调用内核预定义好的辅助函数，不能直接调用任意内核函数。

# 实际验证失败的例子——边界检查不足
$ cat bad.bpf.c
SEC("kprobe/__x64_sys_openat")
int trace_open(struct pt_regs *ctx) {
    char *filename = (char *)PT_REGS_PARM2(ctx);
    char name[256];
    // 错误：bpf_probe_read_user_str需要size参数，但如果size太大...
    bpf_probe_read_user_str(name, sizeof(name), filename);
    // 如果这里再访问name[300]，验证器会拒绝——超出256字节栈
    return 0;
}

# 编译时验证器报错示例
# error: invalid read from stack off -312+400 size 256

2.3 JIT编译：零开销的最后一公里

通过验证的BPF字节码并不会被"解释执行"——而是被JIT编译器翻译为原生机器码。

BPF JIT流程：

1. 分配可执行内存页（带X权限）
2. 逐指令翻译：
   BPF_MOV64_REG(R1, R2)  →  mov %rdi, %rsi    (x86_64)
   BPF_ALU64_ADD(R1, 10)  →  add $10, %rdi
   BPF_EXIT                 →  jmp return_path
3. 刷新指令缓存（icache/dcache同步）
4. 返回bpf_prog结构体，prog->bpf_func指向机器码

# 查看系统中JIT后的BPF程序
cat /proc/kallsyms | grep bpf | head -20

# 观察JIT编译统计
cat /proc/net/bpf_jit_alloc 2>/dev/null || echo "需要内核开启BPF_JIT_DEBUG"

---

三、事件源：BPF程序的触发器

BPF程序不是"主动运行"的——它们必须attach到某个**事件源（Event Source，事件源）**上，等待特定事件触发。

3.1 kprobe/kretprobe：内核函数的望远镜

**kprobe（内核探针）**是最常用的事件源之一。它允许你在几乎任意内核函数的入口或出口插入BPF程序。

graph TD
    A[应用层] -->|read()系统调用| B[sys_read内核函数]
    B -->|触发| C[kprobe: sys_read入口]
    C -->|执行BPF| D[记录参数: fd, count]
    B -->|继续执行| E[实际读取]
    E -->|返回| B
    B -->|触发| F[kretprobe: sys_read出口]
    F -->|执行BPF| G[记录返回值: 实际读取字节数]
    
    style C fill:#ff6b6b,stroke:#333,stroke-width:2px,color:#fff
    style F fill:#ff6b6b,stroke:#333,stroke-width:2px,color:#fff

// BCC示例：跟踪do_nanosleep的延迟
BPF_HASH(start, u32, u64);
BPF_HISTOGRAM(dist);

int entry_do_nanosleep(struct pt_regs *ctx) {
    u32 pid = bpf_get_current_pid_tgid();
    u64 ts = bpf_ktime_get_ns();
    start.update(&pid, &ts);
    return 0;
}

int exit_do_nanosleep(struct pt_regs *ctx) {
    u32 pid = bpf_get_current_pid_tgid();
    u64 *tsp = start.lookup(&pid);
    if (tsp) {
        u64 delta = bpf_ktime_get_ns() - *tsp;
        dist.increment(bpf_log2l(delta / 1000)); // 微秒级直方图
        start.delete(&pid);
    }
    return 0;
}

3.2 tracepoint：内核中的稳定锚点

kprobe的问题是它attach到函数名——而内核函数名经常变化。tracepoint（跟踪点）则不同，它们是内核开发者显式埋下的稳定锚点。

# 查看系统中所有可用的tracepoint
ls /sys/kernel/debug/tracing/events/ | head -20
# block, ext4, irq, jbd2, kmem, net, sched, signal, skb, syscalls, tcp, udp, vmscan...

# 查看具体的tracepoint格式
 cat /sys/kernel/debug/tracing/events/sched/sched_switch/format

tracepoint的优势是ABI稳定。内核开发者承诺：tracepoint的字段和语义不会改变。这使得基于tracepoint的BPF工具可以在内核版本之间移植。

// tracepoint的BPF程序——参数通过struct trace_event_raw_*传递
SEC("tracepoint/sched/sched_switch")
int trace_sched_switch(struct trace_event_raw_sched_switch *ctx) {
    // ctx->prev_pid, ctx->next_pid, ctx->prev_comm, ctx->next_comm
    // 这些字段由内核保证稳定
    bpf_printk("PID %d -> PID %d\n", ctx->prev_pid, ctx->next_pid);
    return 0;
}

3.3 uprobe/uretprobe & USDT：用户态的显微镜

BPF不仅能看内核，还能看用户态程序——不需要修改程序源码或重启进程。

事件源	原理	适用场景
uprobe	在目标进程的用户态函数入口插入断点指令	任意用户态函数
uretprobe	在函数出口处触发（通过栈上保存的返回地址）	测量函数延迟
USDT	用户态静态定义跟踪（User-level Statically Defined Tracing），类似tracepoint	应用主动埋点（MySQL、PostgreSQL、Node.js等）

# 用uprobe跟踪libc的malloc
bpftrace -e 'uprobe:/lib/x86_64-linux-gnu/libc.so.6:malloc { @count = count(); }'

# 查看MySQL的USDT探针
readelf -n /usr/sbin/mysqld | grep NT_STAPSDT

graph LR
    A[BPF程序] -->|attach| B[uprobe]
    B -->|目标| C[任意用户态函数]
    A -->|attach| D[USDT]
    D -->|目标| E[显式埋点的应用函数]
    
    C -.->|不需要源码修改| F[任意可执行文件]
    E -.->|需要应用支持| G[MySQL/Node/Java...]

3.4 其他事件源

事件源	描述
raw_tracepoint	比tracepoint更底层，直接读取原始参数
fentry/fexit	基于BPF trampoline（蹦床），比kprobe开销更低
perf_event	硬件PMU事件（CPU周期、缓存未命中）
socket/XDP/TC	网络包事件
cgroup_skb/sock	cgroup级别的网络过滤
lsm	Linux Security Module钩子

---

四、调用栈回溯与火焰图原理

4.1 BPF如何获取调用栈

BPF提供了bpf_get_stackid()辅助函数，可以在事件触发时捕获当前调用栈。

BPF_STACK_TRACE(stack_traces, 10240);  // 最多存储10240个栈

int trace_on_cpu(struct pt_regs *ctx) {
    u32 pid = bpf_get_current_pid_tgid() >> 32;
    // 获取栈ID——去重后的调用栈标识
    int stack_id = stack_traces.get_stackid(ctx, BPF_F_USER_STACK | BPF_F_FAST_STACK_CMP);
    
    struct key_t key = {.pid = pid, .stack_id = stack_id};
    u64 *val = counts.lookup(&key);
    if (val) (*val)++;
    else counts.update(&key, &(u64){1});
    
    return 0;
}

graph TD
    A[事件触发: 某函数被调用] --> B[BPF程序执行]
    B --> C[调用bpf_get_stackid]
    C --> D[从pt_regs读取IP/BP寄存器]
    D --> E[用户态栈: 遍历RBP链]
    E --> F[内核态栈: 遍历帧指针链]
    F --> G[生成栈文本: 函数名+偏移]
    G --> H[哈希计算得stack_id]
    H --> I{该栈已存在?}
    I -->|是| J[复用已有stack_id]
    I -->|否| K[存储新栈到stack_traces Map]
    K --> L[返回新的stack_id]

4.2 火焰图：从栈样本到可视化洞察

火焰图（Flame Graph，火焰图）不是BPF发明的，但BPF让火焰图的采集变得前所未有的高效。

# 用BPF采集on-CPU栈样本，生成火焰图
# 1. 采集
bpftool prog load oncpu_kprobe.bpf.o /sys/fs/bpf/oncpu_kprobe autoattach
# 或者直接使用现成的BCC工具
/usr/share/bcc/tools/profile -F 99 -adf 30 > out.stacks

# 2. 折叠
/usr/share/bcc/tools/stackcollapse.pl out.stacks > out.folded

# 3. 生成SVG火焰图
flamegraph.pl out.folded > out.svg

graph LR
    A[BPF采集栈样本] -->|高频采样| B[用户态读取Map]
    B -->|折叠格式| C[函数A;函数B;函数C 42]
    C -->|相同栈合并| D[FlameGraph.pl]
    D -->|SVG| E[火焰图可视化]
    
    style E fill:#ff6b6b,stroke:#333,stroke-width:2px,color:#fff

火焰图的阅读法则：

• 宽度 = 该调用栈出现的频率（越宽越热）
• 纵轴 = 调用深度（从下到上是调用链）
• 颜色 = 随机或按类别（用户态/内核态）——颜色本身不承载数值意义
• 横轴 = 不表示时间，只是按字母排序

示例火焰图栈表示：
main;funcA;funcB;do_syscall  [##########]  35%
main;funcA;funcC;do_syscall  [####]        15%
main;funcD;kernel::vfs_read    [########]    28%
...

---

总结

graph TD
    A[BPF架构核心] --> B[10个64位寄存器 + 极简指令集]
    A --> C[BPF Maps: 键值桥梁]
    A --> D[验证器: 形式化安全检查]
    A --> E[JIT: 字节码 → 机器码]
    
    F[BPF生命周期] --> G[编写C代码]
    F --> H[LLVM编译为字节码]
    F --> I[bpf系统调用加载]
    F --> J[验证器严格审查]
    F --> K[JIT编译为机器码]
    F --> L[attach到事件源]
    F --> M[事件触发执行]
    
    N[事件源生态] --> O[kprobe: 任意内核函数]
    N --> P[tracepoint: 稳定ABI锚点]
    N --> Q[uprobe/USDT: 用户态显微镜]
    N --> R[perf_event/XDP/LSM: 硬件与网络]

核心要点

1. BPF是一台虚拟机：十个64位寄存器、~100条指令、512字节栈——极简但完备。
2. BPF Maps是数据桥梁：哈希表、数组、LRU、栈追踪、环形缓冲区……Maps让BPF程序之间、以及BPF与用户空间之间共享数据。
3. 验证器是BPF的灵魂：它用形式化方法保证BPF程序的安全——无循环、有界内存访问、类型安全、白名单函数调用。
4. JIT抹平了虚拟机的性能差距：验证后的字节码被编译为原生机器码，执行效率接近手写内核代码。
5. 事件源的多样性决定了BPF的通用性：从内核函数到用户态应用，从CPU周期到网络包，BPF可以attach到几乎所有系统边界上。
6. 火焰图是BPF的最佳可视化搭档：高效的栈采样 + 火焰图折叠 = 一目了然的性能热点。

小李把那个MySQL追踪脚本整理成了一个可复用的模板。"以前觉得内核是黑盒，"他在笔记里写，"现在发现，BPF就像在黑盒上开了一扇窗——而且这扇窗不会破坏盒子的结构。"

---

本章完。下一章：性能分析——用BPF工具建立系统性能分析的方法论框架。