BTF 与 CO-RE：eBPF 可移植内核编程的工程实战

引言：eBPF 的阿喀琉斯之踵

伯克利数据包过滤器（eBPF）自 Linux 3.18 引入以来，彻底重塑了可观测性、内核追踪与安全监控的版图。然而在生产环境中部署 eBPF 程序，开发者面临一个棘手的现实问题：内核数据结构在不同发行版和版本之间频繁变化。一个在 Ubuntu 22.04 内核 5.15 上编译的 eBPF 对象文件，几乎肯定无法在 RHEL 9 的 5.14 内核上加载——即使版本号看似兼容。

传统方案如 BCC（BPF Compiler Collection）要求在目标机器上实时编译，依赖内核头文件和兼容的 Clang，这把方案在容器化和精简镜像场景中寸步难行。CO-RE（Compile Once, Run Everywhere）应运而生，而 BTF（BPF Type Format）正是 CO-RE 的技术基石。本文将从工程实战角度深入剖析这一关键技术栈。

一、BTF：内核类型信息的轻量镜像

BTF 是一种编码内核和 eBPF 程序类型信息的紧凑格式，类似于调试信息但体积大幅缩减。从 Linux 5.4 开始，Fedora、Ubuntu、Arch 等主流发行版在构建内核时默认启用 CONFIG_DEBUG_INFO_BTF=y，将 BTF 数据嵌入 vmlinux 二进制文件中。

BTF 的核心数据结构可通过 bpftool btf dump file /sys/kernel/btf/vmlinux 查看。它记录了每一个内核类型：

• BTF_KIND_INT — 基础整数类型（如 int、pid_t），携带位宽、符号属性和编码方式
• BTF_KIND_STRUCT — 结构体定义，包含成员名称、位偏移、嵌套类型引用
• BTF_KIND_PTR — 指针类型，指向被引用类型的 ID
• BTF_KIND_TYPEDEF、BTF_KIND_CONST、BTF_KIND_VOLATILE — 类型修饰符链
• BTF_KIND_FUNC 和 BTF_KIND_FUNC_PROTO — 函数签名及其参数类型

BTF 的关键价值在于：eBPF 程序编译时记录的类型"意图"（BTF 描述），执行时与目标机器实际 BTF 进行重定位计算。无论目标机器的 task_struct 怎样变化，libbpf 都能精确定位字段的运行时偏移并自动修正。

二、CO-RE 工作机制：三步重定位

CO-RE 通过 libbpf 在加载阶段执行三个关键步骤：

步骤 1：BPF 对象加载与重定位记录

libbpf_object__open 解析编译后的 ELF 对象文件，读取其中的 .BTF 和 .BTF.ext 段。.BTF.ext 记录每一条需要重定位的指令：例如 "第 X 条指令访问结构体 Y 的成员 Z"。

步骤 2：CO-RE 重定位计算

libbpf 将编译时的类型描述与目标内核的实际 BTF 进行匹配与差异分析：

• 精确匹配：类型定义完全一致，直接使用
• 重写匹配：信息布局发生偏移，计算修正量并写入指令
• 缺失匹配：目标内核不存在该类型字段，加载失败

步骤 3：指令 patch 与验证

libbpf 将计算出的运行时立即数 patch 到 BPF 指令中。BPF 验证器重新执行确保修正后的指令仍满足安全约束。整个流程对用户透明，耗时通常在毫秒级别。

三、实战：编写 CO-RE 追踪 clone 系统调用

下面通过完整的示例演示如何编写一个追踪 clone() 系统调用并统计调用次数的 CO-RE eBPF 程序。项目结构如下：

tfork/
├── Makefile
├── tfork.bpf.c    # eBPF 内核态代码
├── tfork.c        # 用户态加载器
└── tfork.skel.h   # 自动生成的 skeleton

内核态代码 (tfork.bpf.c)

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

struct {
    __uint(type, BPF_MAP_TYPE_HASH);
    __uint(max_entries, 8192);
    __type(key, pid_t);
    __type(value, u64);
} execs SEC(".maps");

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

SEC("tp/syscalls/sys_enter_clone")
int tracepoint__syscalls__sys_enter_clone(struct trace_event_raw_sys_enter *ctx)
{
    u64 id = bpf_get_current_pid_tgid();
    pid_t tid = (pid_t)id;
    u64 *val, zero = 0;

    val = bpf_map_lookup_elem(&execs, &tid);
    if (val) {
        __sync_fetch_and_add(val, 1);
    } else {
        bpf_map_update_elem(&execs, &tid, &zero, BPF_NOEXIST);
    }
    return 0;
}

SEC("kprobe/alloc_pid")
int BPF_KPROBE(trace_alloc_pid, struct pid_namespace *ns)
{
    pid_t tid = bpf_get_current_pid_tgid() >> 32;
    u64 init_val = 1;
    bpf_map_update_elem(&execs, &tid, &init_val, BPF_NOEXIST);
    bpf_printk("CO-RE: new thread created tid=%d", tid);
    return 0;
}

关键点：

• BPF_KPROBE 宏自动生成正确的函数签名，结合 BTF 进行校验
• bpf_printk() 输出通过 /sys/kernel/debug/tracing/trace_pipe 查看
• CO-RE 确保 bpf_get_current_pid_tgid() 等辅助函数在不同内核上行为一致

用户态加载器 (tfork.c)

#include <stdio.h>
#include <unistd.h>
#include <signal.h>
#include <bpf/libbpf.h>
#include "tfork.skel.h"

static volatile bool exiting = false;
static void sig_handler(int sig) { exiting = true; }

int main(int argc, char **argv)
{
    struct tfork_bpf *skel;
    int err;

    signal(SIGINT, sig_handler);
    signal(SIGTERM, sig_handler);
    libbpf_set_strict_mode(LIBBPF_STRICT_ALL);

    skel = tfork_bpf__open();
    if (!skel) { fprintf(stderr, "failed to open BPF skeleton\n"); return 1; }

    err = tfork_bpf__load(skel);
    if (err) { fprintf(stderr, "failed to load: %d\n", err); goto cleanup; }

    err = tfork_bpf__attach(skel);
    if (err) { fprintf(stderr, "failed to attach: %d\n", err); goto cleanup; }

    printf("Started! Ctrl+C to stop.\n");
    while (!exiting) { sleep(5); }

cleanup:
    tfork_bpf__destroy(skel);
    return err != 0;
}

Makefile 构建流程

CLANG ?= clang
LLC ?= llc
ARCH := $(shell uname -m | sed 's/x86_64/x86/' | sed 's/aarch64/arm64/')

all: gen-skels

vmlinux.h:
    bpftool btf dump file /sys/kernel/btf/vmlinux format c > $@

tfork.bpf.o: tfork.bpf.c vmlinux.h
    $(CLANG) -g -O2 -target bpf -D__TARGET_ARCH_$(ARCH) -c tfork.bpf.c -o $@

tfork.skel.h: tfork.bpf.o
    bpftool gen skeleton $< > $@

gen-skels: vmlinux.h tfork.bpf.o tfork.skel.h
clean:
    rm -f vmlinux.h *.o *.skel.h

构建步骤：提取 vmlinux BTF 编译 BPF 对象 skeleton，最后编译用户态代码并链接 libbpf。

四、BPF Skeleton 与 libbpf CO-RE API

BPF skeleton 是 libbpf 自动生成的封装层，简化了加载-附加-销毁生命周期。CO-RE 的关键能力包括：

1. 条件读取与 BTF 依赖追踪

bpf_core_field_exists() 允许运行时检查目标内核是否存在某字段——在多版本兼容场景中极为有用：

if (bpf_core_field_exists(task->real_parent)) {
    // Linux >= 5.11
    ppid = BPF_CORE_READ(BPF_CORE_READ(task, real_parent), tgid);
} else {
    ppid = task->parent->tgid;  // legacy
}

2. BPF_CORE_READ 宏展开

BPF_CORE_READ 在编译时记录操作数 BTF 信息，加载时由 libbpf 重写为正确的裸偏移加载指令。

五、工程实践中的陷阱与优化

陷阱 1：BTF 缺失

如果目标机器 vmlinux 没有 BTF，CO-RE 无法工作。推荐启用 CONFIG_DEBUG_INFO_BTF=y，或在嵌入式场景嵌入压缩 BTF 数据。

陷阱 2：静态函数追踪

eBPF 只能调用已声明的 BPF helper。对 static 的内核函数，可使用 fentry（Linux 5.5+）替代 kprobe。

性能优化

• Per-CPU map：替代普通 HASH map，计数器吞吐量成倍提升
• Ring buffer：Linux 5.8+ 减少中断开销
• 编译选项：必须使用 -O2 -g 保留 BTF

六、从 BCC 迁移到 CO-RE

迁移四步：识别硬编码偏移改 BPF_CORE_READ → 替换参数访问 → 重构内核头为 vmlinux.h → 编译管线切换为预编译 BPF 对象。

BCC 冷启动秒级（含编译），CO-RE skeleton 加载毫秒级。Kubernetes DaemonSet 场景下 pod 启动即采集。

七、CO-RE 工具链全景

• libbpf — 官方 C，完整支持
• cilium/ebpf — Go，Cilium/Tracee 基础
• Aya — Rust，类型安全
• libbpf-rs — Rust 绑定
• bpftrace — 高级追踪语言

总结

CO-RE 和 BTF 是 eBPF 走向生产级基础设施的关键铰链。随着 Linux 6.x 对 fentry/fexit 的完善和 BTF 标准化，CO-RE 将成为 eBPF 程序的默认编译模式。迁移不仅是技术升级，更是生产可靠性的基础保障。