1. 首页
  2. 文章资讯
  3. 编程技术

eBPF CO-RE 深度实战：BTF 类型便携化与可移植 tracing 工具开发

3 阅读 0 评论

eBPF CO-RE 深度实战：BTF 类型便携化与可移植 tracing 工具开发

在可观测性和性能分析领域，eBPF（Extended Berkeley Packet Filter）已经成为 Linux 内核侧最重要的基础设施。然而长期以来，eBPF 程序有一个致命缺陷：每次内核版本升级都可能导致 eBPF 程序崩溃。随着 CO-RE（Compile Once, Run Everywhere）方案的出现，eBPF 程序终于获得了跨内核版本的真正可移植性。本文将深入剖析 CO-CE 的完整技术栈——从 BTF 类型信息获取、libbpf 重定位机制，到生产级 tracing 工具的开发全流程。

一、eBPF 可移植性问题的本质

1.1 传统 eBPF 开发模式

在 CO-RE 之前，编写一个能在多内核版本上运行的 eBPF 程序几乎是一场噩梦。典型工作流程如下：

// 传统方法：硬编码内核数据结构偏移
// 当 struct task_struct 中增加/删除字段时立即失效
SEC("kprobe/do_sys_execve")
int trace_execve(struct pt_regs *ctx) {
    struct task_struct *task = (struct task_struct *)PT_REGS_PARM1(ctx);
    u32 pid = BPF_CORE_READ(task, pid);  // 如果内核 pid 字段偏移变了就崩溃
    return 0;
}

问题根源在于直接编译时嵌入结构体布局依赖，例如结构体增加新字段、字段重命名、字段类型变化都会导致硬编码偏移错位。每次内核升级后都需要在不同目标机器上重新编译 eBPF 字节码，开发效率和部署灵活性极其低下。

1.2 BCC 方案的折中与代价

BCC（BPF Compiler Collection） 是通过预分析内核头文件的动态编译方式工作的：

# BCC 方案：运行时编译，但需要目标环境安装内核头文件
$ sudo python3 trace-execve.py  # 在目标机器上编译

BCC 虽然带来了开发便利，但也有明显缺陷：必须在目标机器上安装完整的 kernel-headers 或启用 BTF 的内核；每次执行都需要编译，冷启动延迟较大；需要 Python 和 LLVM/clang 作为运行时依赖。这显然不适合大规模生产环境部署。

1.3 CO-RE 方案的目标

CO-RE（Compile Once, Run Everywhere） 的核心目标是：一次编译 eBPF 字节码后，能在任意支持 BTF 的目标内核上自动适配数据结构变化。其关键技术支撑来自 ELF 重定位记录、BTF 类型信息和 libbpf 运行时重定位三大组件的协同配合。

二、BTF（BPF Type Format）深度解析

2.1 BTF 是什么

BTF（BPF Type Format） 是编译时由 LLVM 生成的类型信息编码格式，可以理解为内核数据结构的"结构化注释"。当内核编译时启用 CONFIG_DEBUG_INFO_BTF=y，内核自身也会生成完整的 BTF 信息。BTF 信息存储在 ELF 的 .BTF 和 .BTF.ext 段中，可通过以下方式获取：

# 检查内核是否支持 BTF
$ ls /sys/kernel/btf/vmlinux
/sys/kernel/btf/vmlinux

# 提取内核 BTF 信息
$ bpftool btf dump file /sys/kernel/btf/vmlinux format raw > vmlinux.h  # 约 130 万行

# 查看所有内核类型
$ bpftool btf dump file /sys/kernel/btf/vmlinux format c | head -50

2.2 BTF 的核心数据结构

BTF 使用一种紧凑的类型表示方式。理解 BTF 类型有助于我们深入调试 CO-RE 行为：

// BTF 类型 ID 体系
// 1. BTF_KIND_INT      — 基本整数类型 (int, long, etc.)
// 2. BTF_KIND_PTR      — 指针类型
// 3. BTF_KIND_STRUCT   — 结构体类型
// 4. BTF_KIND_UNION    — 联合体类型
// 5. BTF_KIND_ENUM     — 枚举类型
// 6. BTF_KIND_TYPEDEF  — typedef 别名
// 7. BTF_KIND_FUNC     — 函数类型
// 8. BTF_KIND_VAR      — 全局变量
// 9. BTF_KIND_DATASEC  — 数据节（extern 变量声明）

// 示例：obj_struct 类型的 BTF 编码
struct obj_struct {
    int field_a;         // BTF_KIND_INT, size=4, offset=0
    long field_b;        // BTF_KIND_INT, size=8, offset=8
    void *ptr_field;     // BTF_KIND_PTR -> void
    struct inner in;     // BTF_KIND_STRUCT -> struct inner
};

2.3 生成 vmlinux.h

vmlinux.h 是从内核 BTF 提取的包含所有内核类型定义的头文件。使用方法非常简单：

# 1. 安装 bpftool
$ sudo apt install linux-tools-$(uname -r)

# 2. 提取 vmlinux.h
$ bpftool btf dump file /sys/kernel/btf/vmlinux format c > vmlinux.h

// 3. 在 eBPF 程序中引用
#include "vmlinux.h"  // 包含所有内核类型定义
#include <bpf/bpf_helpers.h>
#include <bpf/bpf_tracing.h>
#include <bpf/bpf_core_read.h>

vmlinux.h 为 eBPF 开发带来了两个直接好处：不再需要手动 #include 第三方内核头文件，可以舒适地直接访问任意内核数据结构。

三、libbpf CO-RE 重定位机制

3.1 重定位的基本工作原理

CO-RE 的核心原理可用一句话总结：编译时记录所有类型访问的"位置描述"，运行时利用 BTF 信息计算实际偏移并完成修正。

// 工作流程：
// 1. 编译阶段：clang 遇到 BPF_CORE_READ 宏调用，生成 .BTF.ext 段
//    以及一个或多个 ELF 重定位记录
//    relocation record: (type_id="struct task_struct", accessor="->pid", offset=N)
// 2. 加载阶段：libbpf() 解析这些重定位记录
//    - 读取目标内核的 /sys/kernel/btf/vmlinux
//    - 匹配类型名 → 获取目标内核的 struct task_struct 的 pid 字段偏移
// 3. 修正阶段：将计算得到的偏移"补丁"到 eBPF 指令中

3.2 BPF_CORE_READ 宏家族

BPF_CORE_READ 是 CO-RE 方案的核心工具，它并非函数，而是一系列宏：

// 直接读取字段（已重定位）
#define BPF_CORE_READ(dst, src, a) \
    bpf_probe_read_kernel(dst, sizeof(*(dst)), &((src)->a))

// 带指针解引用的字段读取
#define BPF_CORE_READ_INTO(dst, src, a) \
    BPF_CORE_READ(&dst, src, a)

// 宏链式调用：outer->inner->field
#define BPF_CORE_READ_IMM  // 整数常量访问

// 最常用写法：完全不需要 manual bpf_probe_read
struct task_struct *task = ...;
u32 pid = BPF_CORE_READ(task, pid);  // 一行搞定，自动重定位

// 多级指针访问示例
struct mm_struct *mm = BPF_CORE_READ(task, mm);
unsigned long arg_start = BPF_CORE_READ(mm, arg_start);
unsigned long arg_end = BPF_CORE_READ(mm, arg_end);

3.3 BTF.ext 段的详细内容

.BTF.ext（BTF Extended Information）是 CO-RE 方案的关键补充段，包含三部分：

// .BTF.ext 段内容
struct btf_ext_header {
    __u32 magic;
    __u16 version;
    __u16 flags;
    __u32 hdr_len;
    // 字段重定位信息
    __u32 func_info_rec_size;  // 每条函数信息记录大小
    __u32 func_info_cnt;       // 函数信息记录条数
    // 行信息（用于调试和错误报告）
    __u32 line_info_rec_size;
    __u32 line_info_cnt;
    // 字段重定位记录
    __u32 field_relo_rec_size;
    __u32 field_relo_cnt;
};

四、完整实战：开发 opensnoop-lite

4.1 项目结构

opensnoop-lite/
├── Makefile
├── opensnoop.c（eBPF 内核代码 + 用户空间加载器）
└── vmlinux.h

4.2 eBPF 内核代码

// opensnoop.c - 共享头文件同时包含内核态和用户态代码
#include <vmlinux.h>
#include <bpf/bpf_helpers.h>
#include <bpf/bpf_tracing.h>
#include <bpf/bpf_core_read.h>

#define TASK_COMM_LEN 16
#define NAME_MAX 256

// 事件数据结构
struct event {
    u32 pid;
    u32 uid;
    int ret;
    char comm[TASK_COMM_LEN];
    char filename[NAME_MAX];
};

// BPF map：用于内核态向用户态输出事件
struct {
    __uint(type, BPF_MAP_TYPE_PERF_EVENT_ARRAY);
    __uint(key_size, sizeof(u32));
    __uint(value_size, sizeof(u32));
} events SEC(".maps");

// 临时存储：在 entry/exit 之间传递 filename 指针
struct {
    __uint(type, BPF_MAP_TYPE_HASH);
    __uint(max_entries, 10240);
    __type(key, u32);
    __type(value, struct args_t);
} start SEC(".maps");

struct args_t {
    char filename[NAME_MAX];
};

// tracepoint: syscalls:sys_enter_openat
SEC("tracepoint/syscalls/sys_enter_openat")
int tracepoint__sys_enter_openat(struct trace_event_raw_sys_enter *ctx)
{
    u64 id = bpf_get_current_pid_tgid();
    u32 pid = id >> 32;
    struct args_t args = {};

    // CO-RE 核心操作：安全地通过 PT_REGS_PARM 读取参数
    // BPF_CORE_READ 会自动处理类型重定位
    const char *filename = (const char *)PT_REGS_PARM2(ctx);
    bpf_probe_read_user_str(args.filename, sizeof(args.filename), filename);

    bpf_map_update_elem(&start, &pid, &args, BPF_ANY);
    return 0;
}

// tracepoint: syscalls:sys_exit_openat
SEC("tracepoint/syscalls/sys_exit_openat")
int tracepoint__sys_exit_openat(struct trace_event_raw_sys_exit *ctx)
{
    u64 id = bpf_get_current_pid_tgid();
    u32 pid = id >> 32;
    struct args_t *args;
    struct event e = {};

    args = bpf_map_lookup_elem(&start, &pid);
    if (!args)
        return 0;

    bpf_map_delete_elem(&start, &pid);

    e.pid = pid;
    e.uid = bpf_get_current_uid_gid();
    e.ret = ctx->ret;
    bpf_get_current_comm(&e.comm, sizeof(e.comm));
    bpf_probe_read_kernel_str(&e.filename, sizeof(e.filename), args->filename);

    bpf_perf_event_output(ctx, &events, BPF_F_CURRENT_CPU, &e, sizeof(e));
    return 0;
}

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

4.3 用户空间加载器和事件处理

// opensnoop.c（用户空间部分，通过 include "openskeleton.h" 或自行管理）
#include <stdio.h>
#include <unistd.h>
#include <signal.h>
#include <bpf/libbpf.h>
#include "opensnoop.skel.h"  // bpftool 生成的骨架

static volatile bool exiting = false;

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

static int handle_event(void *ctx, void *data, size_t data_sz) {
    const struct event *e = data;
    printf("%-6d %-6d %-8s %s\n", e->pid, e->uid, e->comm,
           e->ret < 0 ? "[FAIL]" : e->filename);
    return 0;
}

static int handle_lost_events(void *ctx, unsigned long long cnt) {
    fprintf(stderr, "lost %llu events\n", cnt);
    return 0;
}

int main(int argc, char **argv) {
    struct opensnoop_bpf *skel;
    struct ring_buffer *rb = NULL;
    int err;

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

    // 1. 打开并加载 eBPF 程序
    skel = opensnoop_bpf__open();
    if (!skel) {
        fprintf(stderr, "Failed to open BPF skeleton\n");
        return 1;
    }

    // 2. 加载到内核（CO-RE 重定位在此步骤完成！）
    err = opensnoop_bpf__load(skel);
    if (err) {
        fprintf(stderr, "Failed to load BPF skeleton: %d\n", err);
        goto cleanup;
    }

    // 3. attach
    err = opensnoop_bpf__attach(skel);
    if (err) {
        fprintf(stderr, "Failed to attach BPF skeleton: %d\n", err);
        goto cleanup;
    }

    // 4. 设置环形缓冲区
    rb = ring_buffer__new(bpf_map__fd(skel->maps.events), handle_event, NULL, NULL);
    if (!rb) {
        fprintf(stderr, "Failed to create ring buffer\n");
        err = 1;
        goto cleanup;
    }

    printf("Tracing openat()... Ctrl-C to end.\n");
    printf("%-6s %-6s %-8s %s\n", "PID", "UID", "COMM", "FILENAME");

    while (!exiting) {
        err = ring_buffer__poll(rb, 100);
        if (err == -EINTR) { err = 0; break; }
        if (err < 0) { fprintf(stderr, "Error polling ring buffer: %d\n", err); break; }
    }

cleanup:
    ring_buffer__free(rb);
    opensnoop_bpf__destroy(skel);
    return err != 0;
}

4.4 Makefile — bpftool skeleton 自动生成

# Makefile 示例：一条命令完成编译、骨架生成、部署
APP = opensnoop

# BTF 支持检测 $(CLANG) $(LLVM_STRIP) bpftool
BPF_CFLAGS = -g -O2 -target bpf -D__TARGET_ARCH_$(ARCH)

.PHONY: clean vmlinux $(APP)

# 生成 vmlinux.h (仅首次或内核更新时需要)
vmlinux:
    bpftool btf dump file /sys/kernel/btf/vmlinux format c > vmlinux.h

# 编译 eBPF 字节码
$(APP).bpf.o: $(APP).c vmlinux.h
    $(CLANG) $(BPF_CFLAGS) -c $< -o $@
    $(LLVM_REGISTER_STATE_MODEL) $@

# 生成 skeleton 头文件
$(APP).skel.h: $(APP).bpf.o
    bpftool gen skeleton $@ < $(APP).bpf.o > $(APP).skel.h

# 编译用户空间程序
$(APP): $(APP).c $(APP).skel.h
    $(CC) $(CFLAGS) -Wall -o $@ $< -lbpf -lelf -lz

clean:
    rm -f $(APP) $(APP).bpf.o $(APP).skel.h

五、条件编译与跨内核版本兼容

5.1 libbpf 提供的版本检测 API

不同内核版本提供的 helper 函数和特性不同，libbpf 提供了运行时版本检测：

#include <bpf/libbpf.h>

// 运行时版本检测
__u32 libbpf_major_version(void);
__u32 libbpf_minor_version(void);

// 内核版本检测
__u32 get_kernel_version(void);  // 返回 LINUX_VERSION_CODE

// 使用示例
struct opensnoop_bpf *skel = opensnoop_bpf__open();

// 内核版本低于 5.5 时的兼容处理
#if LINUX_VERSION_CODE < KERNEL_VERSION(5, 5, 0)
    bpf_program__set_autoload(skel->progs.tracepoint__sys_exit_openat, false);
#endif

opensnoop_bpf__load(skel);

5.2 可选字段与 __builtin_preserve_access_index

CO-RE 通过 __builtin_preserve_access_index 内建函数处理"可选字段"——即某些内核版本中存在、其他版本中不存在的结构体字段：

// 例子：struct tcp_sock 在不同内核版本中新增/变更的字段
static __always_inline u32 get_snd_cwnd(struct sock *sk) {
    // CO-RE 会处理字段不存在的情况
    // 如果目标内核没有该字段，返回 0
    return BPF_CORE_READ(sk, sk_sndbuf);
}

// 更复杂的例子：读取可能不存在的字段并设置默认值
struct tcp_sock *tcp_sk = (struct tcp_sock *)sk;
u32 snd_cwnd = BPF_CORE_READ(tcp_sk, snd_cwnd);
// 如果 snd_cwnd 字段不存在，重定位会失败，但 libbpf 可以通过
// BPF_SKEL_MAPPING 或 bpf_core_field_exists() 提前检查
if (bpf_core_field_exists(tcp_sk->snd_cwnd)) {
    snd_cwnd = BPF_CORE_READ(tcp_sk, snd_cwnd);
}

5.3 使用 BPF_KPROBE 宏适应不同内核函数签名

不同内核版本中，kprobe 挂载点函数的参数名可能变化：

// 方法一：使用 BPF_KPROBE 宏自动处理参数（推荐）
SEC("kprobe/do_sys_execve")
int BPF_KPROBE(do_sys_execve, const char *filename,
               const char *const *argv, const char *const *envp)
{
    // 无需手动通过 PT_REGS_PARMx(ctx) 读取参数
    bpf_printk("execve: %s\n", filename);
    return 0;
}

// 方法二：直接 PT_REGS_PARM 读取（需要确切知道寄存器映射）
SEC("kprobe/do_sys_execve")
int kprobe__do_sys_execve(struct pt_regs *ctx)
{
    const char *filename = (const char *)PT_REGS_PARM1(ctx);
    // ...
}

六、高级技巧：自定义数据结构与只读数据

6.1 只读配置数据

CO-RE 可以通过 .rodata 段向 eBPF 程序传递编译时配置参数：

// 定义只读配置
volatile const struct {
    u32 target_pid;
    u32 target_uid;
    bool verbose;
} ro_config SEC(".rodata");

SEC("tp/syscalls/sys_enter_openat")
int handle_sys_enter_openat(struct trace_event_raw_sys_enter *ctx) {
    u32 pid = bpf_get_current_pid_tgid() >> 32;

    // 应用过滤器
    if (ro_config.target_pid != 0 && pid != ro_config.target_pid)
        return 0;

    // 用户空间可以只修改 .rodata 段重新加载配置
    // 无需重新编译 eBPF 程序
}

6.2 BPF Map 类型选择指南

CO-RE 程序编写中与 map 相关的几个最佳选择：

+------------------+--------------------------------+-------------------------+
| 场景             | 推荐 Map 类型                  | 说明                    |
+------------------+--------------------------------+-------------------------+
| 用户态↔内核态    | BPF_MAP_TYPE_RINGBUF          | Linux 5.8+ 性能最佳    |
| 事件流           | BPF_MAP_TYPE_PERF_EVENT_ARRAY  | 传统方式，兼容性更好    |
| 哈希表缓存       | BPF_MAP_TYPE_HASH 或          | 自动 LRU（需设置 flag）  |
|                  | BPF_MAP_TYPE_LRU_HASH         |                         |
| LPM 前缀匹配     | BPF_MAP_TYPE_LPM_TRIE         | CIDR 等场景             |
| 数组（固定大小） | BPF_MAP_TYPE_ARRAY            | 最快，按键直接访问       |
| Per-CPU 统计     | BPF_MAP_TYPE_PERCPU_ARRAY     | 多 CPU 无需加锁          |
| TCP socket 附加  | BPF_MAP_TYPE_SOCKMAP         | 网络加速场景             |
+------------------+--------------------------------+-------------------------+

七、eBPF Verifier 与 CO-RE 协同工作原理

7.1 Verifier 的核心职责

每次 eBPF 程序加载时，内核的 eBPF verifier 会完整分析程序的安全性和正确性。CO-RE 生成的代码会经过 verifier 的几条额外检查：

// Verifier 对 CO-RE 程序的额外检查
// 1. 读取范围验证：BPF_CORE_READ 是否可能越界访问
// 2. 空指针检测：CO-RE 读取是否包含空指针解引用风险
// 3. 类型一致性：源类型和目标类型是否 BTF 匹配
// 4. 循环复杂度和指令条数限制（1M 条）

7.2 常见 verifier 错误与 CO-RE 解决方案

// 错误示例：Verifier 无法证明读取范围安全
struct task_struct *leader = BPF_CORE_READ(group_leader);
const char *comm = BPF_CORE_READ(leader, comm);  // 可能失败

// 修复方案：添加 NULL 检查
struct task_struct *leader = BPF_CORE_READ(group_leader);
if (!leader) return 0;
const char *comm = BPF_CORE_READ(leader, comm);

// 错误示例：读取跨越两个 map 边界的字段
// 修复方案：使用 bpf_core_read() 显式指定字节数
char buf[64];
bpf_core_read(buf, sizeof(buf), &some_ptr->field);

八、从 BCC 迁移到 CO-RE + libbpf

8.1 迁移路径

已有 BCC 工具项目的迁移流程如下：

// BCC 代码（Python）
#!/usr/bin/env python3
from bcc import BPF

text = """
BPF_HISTOGRAM(dist);
int kprobe__do_sys_openat2(struct pt_registers *ctx) {
    dist.increment(bpf_log2l(1));
    return 0;
}
"""

b = BPF(text=text)
b.trace_print()

// 等价 CO-RE 代码（C）
struct {
    __uint(type, BPF_MAP_TYPE_HASH);
    __uint(max_entries, 8192);
    __type(key, u64);
    __type(value, u64);
} dist SEC(".maps");

SEC("kprobe/do_sys_openat2")
int BPF_KPROBE(kprobe__do_sys_openat2)
{
    u64 key = bpf_log2l(1), init_val = 0;
    u64 *val = bpf_map_lookup_or_try_init(&dist, &key, &init_val);
    if (val) __sync_fetch_and_add(val, 1);
    return 0;
}

8.2 迁移收益对比

+----------------+---------------------+---------------------------+
| 维度           | BCC                 | CO-RE + libbpf            |
+----------------+---------------------+---------------------------+
| 运行时依赖     | Python + LLVM +     | 仅 libbpf.so (约 1MB)     |
|                | kernel-headers      |                           |
| 二进制大小     | 运行时编译的字节码   | 可执行文件约 100KB        |
| 冷启动时间     | 500ms ~ 2s+         | < 50ms                   |
| 跨版本迁移     | 无需预编译          | 需要目标内核启用 BTF       |
| 编译后可移植   | 否                  | 是 (Compile Once, Run     |
|                |                     |     Everywhere)           |
| 生产部署       | 困难                | 理想                      |
+----------------+---------------------+---------------------------+

九、生产环境部署最佳实践

9.1 分布式集群中的一致部署

在 Kubernetes 或裸金属集群中部署 CO-RE eBPF 程序的推荐模式：

# DaemonSet 部署示例 (简化)
# bpf-daemonset.yaml
apiVersion: apps/v1
kind: DaemonSet
metadata:
  name: opensnoop
spec:
  selector:
    matchLabels:
      app: opensnoop
  template:
    spec:
      hostPID: true    # eBPF 需要
      containers:
      - name: opensnoop
        image: my-repo/opensnoop:latest
        securityContext:
          privileged: true  # 或配置 CAP_BPF + CAP_PERFMON
        resources:
          limits:
            memory: "64Mi"
            cpu: "100m"
        volumeMounts:
        - name: kernel-btf
          mountPath: /sys/kernel/btf
          readOnly: true
      volumes:
      - name: kernel-btf
        hostPath:
          path: /sys/kernel/btf

9.2 最小权限模式

生产环境不应使用 privileged 模式，应精确配置 capabilities：

// 最小 capabilities 配置
securityContext:
  capabilities:
    add:
    - CAP_BPF          # eBPF 程序加载（Linux 5.8+）
    - CAP_PERFMON      # perf_event/性能计数器访问
    - CAP_SYS_PTRACE   # 内核 tracing（部分情况需要）
    - CAP_NET_ADMIN    # XDP/TC 网络程序（网络类 eBPF）

9.3 容器化 eBPF 编程的终极解法：BTFGen

对于没有自带 BTF 的内核（如旧发行版或云内核），可以通过 BTFGen 为任意内核生成精简 BTF 片段：

# BTFGen 工作流程
# 1. 在参考内核上运行 BTFGen，提取所需类型信息
$ btftool gen min_core_btf /sys/kernel/btf/vmlinux \
    my_prog.btf my_prog.btf.ext

# 2. 将精简 BTF 嵌入到可执行文件中
# 3. 即使目标内核无 BTF，也能通过嵌入的 BTF 片段工作

十、主流 CO-RE eBPF 项目实践

10.1 libbpf-bootstrap — 官方学习脚手架

# https://github.com/libbpf/libbpf-bootstrap
git clone https://github.com/libbpf/libbpf-bootstrap.git
cd libbpf-bootstrap/examples/c
make bpftool glibc

# 结构
# bootstrap/  — 最小化 uprobe 示例（推荐入门）
# minimal/    — 最简 kprobe 示例
# uprobe/     — 用户空间函数追踪
# kprobe/     — 内核函数追踪
# fentry/     — 使用 fentry/fexit (性能更优)
# tc/         — TC 流量控制
# sockfilter/ — socket filter
# cgroup/     — cgroup 控制器

10.2 生产级 eBPF 工具

| 项目            | 功能                  | CO-RE 状态    | 链接                                |
|-----------------|-----------------------|---------------|-------------------------------------|
| BCC             | 早期 eBPF 工具集      | 部分          | github.com/iovisor/bcc              |
| bpftool         | eBPF 程序/Map 管理工具 | 完全          | linux/tools/bpf/bpftool             |
| Tetragon        | 基于 eBPF 的运行时安全 | 完全          | github.com/cilium/tetragon          |
| Pixie           | 云原生应用可观测性     | 完全          | github.com/pixie-io/pixie           |
| Cilium          | CNI 网络插件          | 完全          | github.com/cilium/cilium            |
| Falco           | 云原生安全审计        | 迁移中        | github.com/falcosecurity/falco      |
| Tracee          | 安全事件追踪          | 完全          | github.com/aquasecurity/tracee      |

# 推荐学习路径
# 1. 使用 bpftool 操作已有 map/program
# 2. 基于 libbpf-bootstrap 编写最小示例
# 3. 阅读 Pixie / Tetragon 源码
# 4. 独立实现生产级 eBPF 工具

总结

CO-RE 方案和 BTF 类型信息彻底解决了 eBPF 程序的可移植性问题，使得"一次编译、到处运行"在 eBPF 领域成为现实。完整技术栈包括：BTF 类型信息作为运行时重定位的基石，libbpf 的 skeleton 自动生成将用户空间代码量减少九成，bpftool skeleton 管理简化了开发工作流。从 BCC 迁移到 CO-RE + libbpf 虽然有一定学习成本，但能换来显著的部署和运维收益。对于任何需要在生产环境部署可移植 eBPF 程序的工程师来说，掌握 CO-RE 已经是必备技能。未来随着 BPF 语言标准的进一步完善、eBPF 对用户态程序追踪支持的增强，CO-RE 的应用范围将进一步扩展到更多场景。

点赞(0) 打赏
XDP 与 eBPF 高性能网络包处理深度工程实战：从驱动层 DPDK 替代到可编程数据包处理架构
XDP 与 eBPF 高性能网络包处理深度工程实战：从驱动层 DPDK 替代到可编程数据包处理架构
eBPF CO-RE 深度实战：BTF 类型便携化与可移植 tracing 工具开发
eBPF CO-RE 深度实战：BTF 类型便携化与可移植 tracing 工具开发
Linux XDP (eXpress Data Path): 内核包处理的最短路径深度工程实战
Linux XDP (eXpress Data Path): 内核包处理的最短路径深度工程实战
BPF Arena: Atomic Shared Memory Between Kernel and Userspace for Next-Generation Observability
BPF Arena: Atomic Shared Memory Between Kernel and Userspace for Next-Generation Observability

评论列表 共有 0 条评论

暂无评论
立即
投稿

微信公众账号

微信扫一扫加关注

 发表
评论 返回
顶部