BPF CO-RE libbpf-rs：免重编译的可移植内核追踪深度实战

在生产环境中部署 eBPF 程序时，开发者面临的最大痛点并非 BPF 指令的复杂性，而是可移植性。BPF CO-RE（Compile Once, Run Everywhere）彻底改变了这一局面。本文将深入 BPF CO-RE 的核心机制——BTF（BPF Type Format）、内核重定位记录、以及 libbpf-rs 在 Rust 生态中的实践，并通过多个生产级案例展示如何构建真正"一次编译，到处运行"的 eBPF 工具。

一、为什么传统 eBPF 方式在生产环境行不通

1.1 传统 BCC 模式的困境

BCC（BPF Compiler Collection）是最早的 eBPF 开发框架之一，它的运行模式是在目标机器上即时编译 BPF 代码：

用户态脚本 (Python) ──→ LLVM/Clang ──→ BPF 字节码 ──→ 内核
               └── 需要目标内核的头文件 ──┘

这种模式的问题显而易见：需要内核头文件、编译工具链占用空间大、编译耗时长、ABI 不兼容风险高。

1.2 预编译模式的局限

预编译面临的核心问题是：内核数据结构在不同版本之间会变化字段名、偏移量、甚至整个结构体布局。struct task_struct 在 5.15 和 6.1 内核中，pid 字段的偏移可能不同。

二、BPF CO-RE 的核心机制

BPF CO-RE 由 BTF、编译器重定位记录、libbpf 运行时加载和字段重定位四个关键技术组成。

2.1 BTF（BPF Type Format）

BTF 是一种紧凑的类型编码格式，描述了内核中所有结构体、联合体、枚举和函数签名。主流发行版（Ubuntu 20.04 、Fedora 32 、CentOS 8 ）默认开启。

# 查看 vmlinux 中的 BTF 类型数量
bpftool btf dump file /sys/kernel/btf/vmlinux format raw | wc -l

# 查看特定结构体
bpftool btf dump file /sys/kernel/btf/vmlinux format c | grep -A 5 "struct task_struct"

2.2 编译器重定位记录

当使用 clang -g 编译 BPF 程序时，Clang 会在 BPF ELF 重定位段中生成重定位记录。

# 查看 BPF 程序中的重定位信息
readelf -r bpf_program.o

# 输出示例：
# Offset     Type              Value               Name
# 00000000   R_BPF_64_ABS      btf_str             task_struct___pid

2.3 libbpf 的运行时加载

libbpf.so 在加载 BPF 程序时：读取 .BTF 和 .BTF.ext 段 → 读取目标内核 BTF → 对比类型信息计算差异 → 原地修改 BPF 指令中的立即数 → 提交验证器验证。

三、libbpf-rs：Rust 生态中的 CO-RE 利器

3.1 项目结构

bpf-core-project/
├── Cargo.toml                    # 用户态
├── build.rs                      # 构建脚本
├── src/
│   └── main.rs                   # 用户态逻辑
└── bpf/
    ├── Cargo.toml                # BPF 端
    └── probe.bpf.c               # BPF 程序代码

3.2 build.rs 配置

use libbpf_cargo::SkeletonBuilder;

fn main() {
    SkeletonBuilder::new()
        .source("bpf/probe.bpf.c")
        .build_and_generate("src/probe.skel.rs")
        .unwrap();
}

四、实战案例一：可移植的系统调用追踪

BPF 端代码

// bpf/probe.bpf.c
#include "vmlinux.h"
#include