要真正理解 eBPF 的革命性，我们不能从结论出发，必须回到最基本的问题： 操作系统内核是如何工作的？为什么给内核添加新功能如此困难？ 只有建立了这个认知根基，eBPF 的设计哲学才会显得不仅合理，而且必然。

1.1 内核空间 vs 用户空间：城堡与护城河

想象一座中世纪城堡。城堡内部（Kernel Space，内核空间）是王国的心脏—— 这里掌管着一切核心资源：军队调度（CPU 调度）、粮仓管理（内存管理）、城门通信（网络协议栈）、 档案室（文件系统）。城堡的管理者拥有最高权限——Ring 0， 可以直接操作任何硬件设备，访问全部物理内存。

城堡外面是繁华的集市（User Space，用户空间）。商人（应用程序）们在这里做生意、 交换信息、服务客户。他们很重要，但绝不被允许直接走进城堡。 为什么？因为一个恶意的（或仅仅是粗心的）商人如果能直接接触到粮仓， 可能导致整个王国的崩溃——这在计算机术语中叫做 Kernel Panic， 即内核崩溃导致整个系统宕机。

这座城堡的安全设计源于 CPU 硬件本身。现代处理器（x86-64、ARM64）提供了保护环（Protection Rings）机制： 内核运行在 Ring 0（最高特权），用户应用运行在 Ring 3（最低特权）。这不是软件约定，而是硅片级的物理隔离。 当 Ring 3 的代码试图执行只有 Ring 0 才能执行的指令（例如直接读写 I/O 端口），CPU 会立刻触发一个硬件异常， 操作系统随即终止该进程——这就是"保护"的物理含义。

System Call：城堡的吊桥

既然用户态程序不能直接进入内核，它们如何请求内核服务？答案是 System Call（系统调用）—— 这是用户空间与内核空间之间唯一合法的通信通道。

把它想象成城堡的吊桥：集市的商人（应用程序）想要运送货物到远方（发送网络数据包）， 不能自己翻越城墙，必须走到吊桥前，按下门铃（触发 syscall 指令），报上身份和请求， 等待城堡卫兵（内核）验证后放行。卫兵代为执行操作，再把结果通过吊桥递回来。

每一次系统调用都意味着一次完整的"边境检查"——术语叫做 Context Switch（上下文切换）。

Context Switch：赛车进站的代价

上下文切换就像 F1 赛车进站（Pit Stop）：赛车必须减速、驶入维修区、换胎、加油、再加速驶出。 即使进站团队训练有素，这个过程也至少需要 2-4 秒——而赛道上的对手可不会停下来等你。

在计算机中，一次 Context Switch 涉及：

• 保存当前所有 CPU 寄存器的值到内存
• 切换页表（虚拟地址空间映射）
• 刷新 TLB（Translation Lookaside Buffer）缓存
• 可能导致 L1/L2 CPU 缓存失效
• 恢复目标上下文的寄存器状态

单次上下文切换的直接成本约为 1-5 微秒——看似微不足道，但在高频场景下（如一台 Web 服务器每秒处理 10 万次请求）， 这些微秒会累积成 显著的性能瓶颈。更关键的是间接成本：缓存被刷新后，CPU 需要重新"预热"数据， 这种缓存污染往往比直接开销还要昂贵数倍。

---

1.2 传统方案的困境：走不通的三条路

在 eBPF 出现之前，开发者想要给内核添加新功能，基本上只有三条路可走。 不幸的是，每一条都布满荆棘。

🛤️ 路径一：修改内核源码

最"正统"的方案——直接修改 Linux 内核源代码。你可以 fork 内核仓库，在网络协议栈里加一个新 Hook， 在调度器里加一段优化逻辑，然后提交 patch 到上游社区。

问题是，Linux 内核是全世界最严格的开源项目之一。一个补丁从提交到合入主线（mainline）的典型周期是 3-5 年。 它需要经过社区评审、多轮修改、合入候选版本（RC）、在各大发行版中验证、最终才会出现在你的生产服务器上。 即便你的公司有能力维护一个自定义内核（如 Google 的 Prodkernel），这也意味着巨大的工程成本和 与上游永久分叉的风险。

对于"今晚就需要修复"的生产问题，这条路是完全走不通的。

🛤️ 路径二：内核模块（LKM）

Linux 提供了一种折中方案：Loadable Kernel Module (LKM)，即可加载内核模块。 你可以编写一个 .ko 文件，通过 insmod 命令动态加载到内核中—— 无需重新编译整个内核，也无需重启。

听起来很完美？问题在于：内核模块运行在 Ring 0， 拥有与内核本身完全相同的权限，但没有任何安全边界。 一个有 bug 的内核模块可以：

• 写入任意内存地址 → 数据损坏
• 进入无限循环 → 整个 CPU 被锁死
• 解引用空指针 → Kernel Panic → 系统宕机
• 引入安全漏洞 → 被攻击者利用进行提权

这就像允许一个未经安检的陌生人直接走进城堡的核心——他可能是友好的工匠， 也可能是伪装的间谍。内核模块没有验证机制、没有沙盒隔离、没有崩溃保护。 在生产环境中加载第三方内核模块，对许多企业的安全团队来说是不可接受的风险。

🛤️ 路径三：用户态方案（Sidecar / Agent）

既然内核态太危险，那就全部在用户态做？这是许多传统安全和网络工具的选择—— 比如以 Sidecar 模式运行的服务网格（如 Istio/Envoy），或以 Agent 模式运行的安全工具。

用户态方案是安全的——它崩溃了最多影响自己的进程，不会拖垮内核。 但代价是性能：每一个网络包从内核到用户态再回到内核， 需要穿越两次 System Call 边界、两次 Context Switch、两次数据拷贝。 在高吞吐场景下（如 100Gbps 网络），这种开销可以吃掉 30-50% 的 CPU 资源。

更致命的是可见性盲区：用户态工具只能看到内核"愿意告诉它"的信息—— 通过 /proc、/sys、netlink 等接口。 那些发生在内核深处的事件（如内核函数调用、调度决策、内存分配路径）， 用户态工具根本看不到。就像试图通过城堡的窗户猜测里面发生了什么—— 你看到的永远是冰山一角。

---

1.3 eBPF 的革命性方案：沙盒中的超能力

eBPF 打破了这个三难困境。它的核心思想可以用一句话概括：

"让用户的代码在内核中运行，但在一个数学证明安全的沙盒里。"

回到城堡类比：eBPF 的做法不是让商人翻墙进入城堡（内核模块的方式）， 也不是让商人在城墙外面大喊（用户态的方式）。而是在城堡内部建立了一系列 "安全工作间"（沙盒）——商人可以进入工作间执行任务， 但工作间的每面墙壁都是由 Verifier（验证器） 用数学方法证明为坚固的。 商人无法凿穿墙壁，无法访问工作间之外的区域，更无法让整座城堡倒塌。

这个方案同时获得了三个此前不可兼得的属性：

从"黑盒猜测"到"白盒观测"的范式转移

eBPF 带来的不仅是技术层面的突破，更是认知范式的转移。

在传统模型下，内核是一个巨大的黑盒。你只能通过有限的接口（/proc/net/tcp、 netstat、ss）窥探它的状态——就像用听诊器试图理解一台发动机的内部运作。 出了问题，你只能猜测、推理、试错。

eBPF 则把内核变成了一个白盒。你可以在内核的任意位置放置探针—— 网络协议栈的每一层、系统调用的每一个入口和出口、调度器的每一次决策、内存分配器的每一次调用—— 然后以微秒级精度实时获取数据，而对系统性能的影响 <2%。

这不是"更好的监控工具"，而是观测能力的质变：从"我们能看到什么取决于内核暴露了什么"， 变成了"我们想看什么就能看什么"。

这是本文的核心章节。我们将跟随一个 eBPF 程序走完它从"出生"到"终结"的每一步。 所有关键技术组件——BTF、CO-RE、Verifier、JIT、Maps、Hooks—— 都将在它们登场的精确时刻被深入剖析，而非作为孤立的百科词条。

想象你手里有一段 C 代码，你的目标是让它在 Linux 内核中安全运行、响应事件、收集数据。 这段代码需要经历七个阶段的淬炼，每一步都有严格的把关者。

一个 eBPF 程序的旅程从一段 C 或 Rust 源代码开始。 这段代码看起来和普通的 C 代码很像，但有两个重要的特殊之处： 它使用 SEC() 宏标注挂载点（告诉 loader 这段程序应该被挂到哪个内核事件上）， 并且只能调用内核预先批准的 Helper 函数。

让我们从一个最简单但完整的例子开始：

C — minimal eBPF program (libbpf)
// hello.bpf.c — 你的第一个 eBPF 程序
#include <linux/bpf.h>
#include <bpf/bpf_helpers.h>

// SEC() 宏：声明程序类型和挂载点
// "tp/syscalls/sys_enter_execve" 表示：
//   挂载到 tracepoint → syscalls → sys_enter_execve 事件
//   即：每当有进程调用 execve() 执行新程序时触发
SEC("tp/syscalls/sys_enter_execve")
int hello_exec(void *ctx)
{
    // bpf_printk：内核 trace 管道输出（调试用）
    bpf_printk("Hello eBPF! A process called execve.\n");
    return 0;
}

// 许可证声明：必须为 GPL 兼容，否则 Verifier 拒绝加载
char LICENSE[] SEC("license") = "GPL";

编译流程：C → LLVM IR → BPF 字节码

写好代码后，我们使用 Clang/LLVM 编译器将其编译为 BPF 字节码：

Shell
# 编译为 BPF 目标的 ELF 文件
clang -O2 -target bpf -g -c hello.bpf.c -o hello.bpf.o

# -O2    : 启用优化（必须，Verifier 对未优化代码很不友好）
# -target bpf : 输出 BPF 架构的目标代码
# -g     : 包含调试信息（生成 BTF 需要）

编译的输出是一个标准的 ELF（Executable and Linkable Format）文件， 但目标架构不是 x86 或 ARM，而是 BPF——eBPF 虚拟机的指令集架构。 根据 IETF RFC 9669 的定义，BPF 指令集有两种编码格式： 基本格式（64 位宽指令）和宽指令格式（128 位）， 包含算术、跳转、内存访问和原子操作等指令类别。

这个 ELF 文件中包含了几个关键部分：

• BPF 字节码：程序本身的指令序列
• BTF 段：类型信息（下文详述）
• Maps 定义：程序需要使用的数据结构声明
• 重定位信息：用于 CO-RE 的字段偏移记录
• 许可证信息：SEC("license") 中声明的内容

BTF：内核数据结构的"X 光翻译手册"

要理解 BTF，先理解它解决的问题。

内核中充满了复杂的数据结构。例如 struct task_struct——它代表一个进程， 包含数百个字段（PID、进程名、内存映射、调度信息……）。eBPF 程序经常需要读取这些结构中的特定字段。 但问题来了：不同内核版本中，同一个结构体的内存布局可能完全不同—— 某个字段在 5.4 内核中偏移量是 648 字节，到了 5.10 可能变成了 672 字节。

传统调试信息格式 DWARF 可以描述这些布局，但它的体积巨大—— 一个内核的完整 DWARF 信息可以达到 数百 MB。 这对于嵌入在内核中运行的 eBPF 来说完全不可接受。

BTF（BPF Type Format）应运而生。它是一种极度精简的类型描述格式， 仅记录 eBPF 程序可能需要的结构体名称、字段名、字段类型和偏移量。 同样的内核类型信息，BTF 的体积仅为 DWARF 的 约 1/100—— 通常只有几 MB，可以直接嵌入内核镜像（vmlinux）中。

CO-RE：一次编译，处处运行

有了 BTF 这张"X 光图"，我们就可以解决跨版本兼容性的终极难题—— 这就是 CO-RE（Compile Once – Run Everywhere）的使命。

把 CO-RE 想象成一个万能电源适配器： 你买了一台笔记本电脑，需要在全世界使用——美国 110V/A 型插头、 日本 100V/A 型、欧洲 230V/C 型、英国 230V/G 型…… 如果你为每个国家编译一个专属充电器（即为每个内核版本单独编译 eBPF 程序）， 那你出门就得带一箱充电器。

CO-RE 的做法是：编译时记录你访问了哪些字段（例如"task_struct 的 comm 字段"）， 加载时读取目标机器上的 BTF 信息（得知"comm 字段在这个内核上的实际偏移是 672"）， 然后在加载过程中自动重写字节码中的偏移量。

---

ELF 文件编译好了。现在，它需要从用户空间进入内核空间——穿越第一章中描述的"城墙"。 这个过程有且只有一个入口：bpf() 系统调用。

bpf() 系统调用：进入内核的唯一入口

C — bpf(2) system call
// 内核暴露的系统调用接口
int bpf(int cmd, union bpf_attr *attr, unsigned int size);

// 关键命令：
// BPF_PROG_LOAD  — 加载 eBPF 程序到内核
// BPF_MAP_CREATE — 创建 BPF Map
// BPF_LINK_CREATE — 将程序挂载到 Hook 点
// BPF_PROG_ATTACH — 附着程序到目标
// ...

当用户态程序（Loader）调用 bpf(BPF_PROG_LOAD, ...) 时， 它将 ELF 中的 BPF 字节码传递给内核。但字节码不会直接执行—— 它首先必须通过 eBPF 世界中最严厉的守门人：Verifier（验证器）。

Verifier：内核的"最高法院"

如果 eBPF 的安全性有一个总设计师，那就是 Verifier。 它是整个 eBPF 架构中最关键、最复杂的组件—— 没有它，eBPF 就只是另一种内核模块，存在一切内核模块的风险。

把 Verifier 想象成一座城堡的最高法院： 每一段代码要进入城堡，必须先在法庭上接受逐行审判。 法官不听辩护词、不看推荐信——他只看证据（代码本身）， 并亲自走遍程序所有可能的执行路径， 确认每一步都不会危害城堡的安全。只要有一条路径存在风险， 整个程序就会被驳回——没有例外，没有上诉。

Verifier 的核心算法可以概括为五个步骤：

第一步：有界深度优先搜索（Bounded DFS）。 Verifier 从程序的入口指令开始，沿着控制流图的每一条分支递归遍历。 遇到 if-else，它会分别进入两条路径； 遇到循环，它会展开有限次迭代（在 Linux 5.3+ 中支持有界循环，但循环次数必须在编译期可确定）。 注意：这不是简单的 DAG（有向无环图）遍历—— eBPF 程序可以包含有界循环和复杂的条件分支，Verifier 必须处理这些情况。

第二步：寄存器状态追踪。 在每一步，Verifier 都维护着 11 个寄存器（R0-R10）的完整状态快照。 每个寄存器的状态不仅包括"当前值"，还包括它的类型（标量值、Map 指针、栈指针、NULL……）、 值范围（例如 R3 ∈ [0, 1024]）和对齐方式。 当代码执行 map_lookup_elem() 返回结果到 R0 时， Verifier 将 R0 标记为 MAP_VALUE_OR_NULL——它可能是有效指针，也可能是 NULL。 如果后续代码不检查 NULL 就直接解引用（*R0），Verifier 会立刻拒绝。

第三步：状态剪枝（State Pruning）。 如果没有剪枝，路径数量会随分支数指数级增长。 剪枝的核心思想是：如果程序到达某个点时的寄存器状态是之前已验证过的某个状态的 子集（即更受限），那么这条路径一定也是安全的——无需重复验证。 这将指数级复杂度降低到可控范围。

第四步：逐指令安全性检查。对每条指令，Verifier 检查：

• 内存访问是否在合法范围内？（栈空间 512 字节、Map 值边界、数据包边界）
• 指针算术是否可能导致越界？
• 是否存在未初始化的寄存器读取？
• Helper 函数的参数类型是否匹配？
• 是否存在可能的除零错误？

第五步：终止性保证。 程序的总指令复杂度不得超过 100 万条（自 Kernel 5.2 起， 此前为 4096 条）。所有循环必须有可证明的有限迭代次数。 这从数学上保证了程序必然终止——不会在内核中陷入死循环。

---

程序通过了 Verifier 的审判，证明是安全的。但此时它仍然是 BPF 字节码—— 一种中间表示（IR），类似 Java 的 bytecode。 如果直接解释执行这些字节码，每条指令都需要一个"指令分发循环"（fetch-decode-execute）， 性能会比原生代码慢 5-10 倍。

这就是 JIT（Just-In-Time）编译器登场的时刻。 JIT 将 BPF 字节码一对一翻译为目标 CPU 的原生机器指令—— x86-64 上是 Intel/AMD 指令，ARM64 上是 ARM 指令。 翻译完成后，BPF 字节码被丢弃，后续每次执行的都是纯粹的原生代码， 没有任何解释开销。

寄存器映射：虚拟到物理的零开销桥梁

eBPF 设计的精妙之处在于，它的虚拟寄存器 R0-R9 与现代 CPU 的物理寄存器之间 存在近乎完美的一一映射关系，如同为 JIT 量身定制。

这意味着 JIT 在翻译时几乎不需要额外的寄存器搬移指令—— BPF 的 R1 直接就是 x86-64 的 rdi（函数第一参数寄存器）， R0 直接就是 rax（返回值寄存器）。 这种设计使得 JIT 编译后的代码与手写汇编几乎零性能差距。

L3 实操 · 用 bpftool 查看 JIT 输出

你可以使用 bpftool 直接查看 JIT 编译后的机器指令：

Shell — bpftool JIT dump
# 查看已加载的 eBPF 程序列表
$ bpftool prog list
42: tracepoint  name hello_exec  tag a1bc...  gpl
     loaded_at 2026-04-07T14:30:00+0900  uid 0
     xlated 96B  jited 68B  memlock 4096B

# 查看 BPF 字节码（xlated = 经过 Verifier 后的中间表示）
$ bpftool prog dump xlated id 42
   0: (b7) r1 = 0x6f57206f6c6c6548   // "Hello Wo"
   1: (6b) *(u16 *)(r10 - 4) = r1
   2: (b7) r1 = 0x21646c72           // "rld!"
   ...

# 查看 JIT 编译后的原生机器码 ← 这才是 CPU 实际执行的
$ bpftool prog dump jited id 42
   0xffffffffc0750001:
   0:   push   rbp                  // 保存栈帧
   1:   mov    rbp, rsp             // 建立新栈帧
   4:   sub    rsp, 0x10            // 分配栈空间
   8:   movabs rdi, 0x6f57206f6c6c6548
   12:  mov    QWORD PTR [rbp-16], rdi
   ...
   52:  call   0xffffffffc0123456  // bpf_trace_printk
   57:  xor    eax, eax             // return 0
   59:  leave
   60:  ret

C — minimal eBPF program
// hello.bpf.c — Your first eBPF program
#include <linux/bpf.h>
#include <bpf/bpf_helpers.h>

SEC("tp/syscalls/sys_enter_execve")
int hello_exec(void *ctx)
{
    bpf_printk("Hello eBPF! A process called execve.\n");
    return 0;
}

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

Shell
# List loaded eBPF programs
$ bpftool prog list
42: tracepoint  name hello_exec  tag a1bc...
     xlated 96B  jited 68B  memlock 4096B

# Dump JIT-compiled native code
$ bpftool prog dump jited id 42
   0:   push   rbp
   1:   mov    rbp, rsp
   ...
   52:  call   0xffffffffc0123456   // bpf_trace_printk
   57:  xor    eax, eax
   59:  leave
   60:  ret

eBPF 程序在内核中运行、收集数据、做出决策——但这些信息如果无法传递到用户空间， 就像一个在前线侦察的特工无法向总部汇报——再好的情报也毫无意义。

eBPF 生态中解决这个问题的核心机制叫做 BPF Maps—— 它是内核态和用户态之间的高速数据通道。

BPF Maps：理解为"内核中的共享数据库"

BPF Map 是一种驻留在内核内存中的键值存储结构。 它同时对 eBPF 程序（内核态）和用户态程序可见—— eBPF 程序通过 Helper 函数读写 Map，用户态程序通过 bpf() 系统调用读写同一个 Map。 这就建立了一条绕过传统 System Call 数据路径的高效通道。

Linux 内核提供了多种 Map 类型，每种针对不同的使用场景：

Ring Buffer vs Perf Buffer：2025 最佳实践

当 eBPF 程序需要将事件数据流（如每次 syscall 的参数、每个网络连接的元数据） 推送到用户态时，有两种主要的 Map 类型可选： 传统的 Perf Buffer（Linux 4.4+）和新一代的 Ring Buffer（Linux 5.8+）。

---

完整代码示例：从最简到完整

现在让我们把生命周期中学到的所有概念串联起来，通过两个渐进式的代码示例来实践。

示例一：最小 BCC 示例（3 行核心 Python）

BCC（BPF Compiler Collection）是入门 eBPF 最快的方式—— 它在运行时编译 C 代码，隐藏了 ELF 解析、Verifier 交互、Map 管理等所有底层细节。 代价是每次运行都需要 LLVM 和内核头文件（适合开发调试，不适合生产部署）。

Python — BCC (最简版)
#!/usr/bin/env python3
# trace_execve.py — 追踪所有 execve 系统调用
from bcc import BPF

# 内嵌的 eBPF C 代码
prog = """
int hello(void *ctx) {
    bpf_trace_printk("exec called\\n");
    return 0;
}
"""

# 三行核心代码：编译 → 挂载 → 读取
b = BPF(text=prog)                                 # ① 编译 C → BPF 字节码
b.attach_kprobe(event="__x64_sys_execve", fn_name="hello")  # ② 挂载到 execve
b.trace_print()                                      # ③ 读取 trace 管道输出

示例二：完整 libbpf 范式（生产级）

这是现代 eBPF 开发的标准范式——分为内核态 C 程序和用户态 C 程序， 通过 libbpf skeleton 自动关联。这个示例追踪 execve() 调用， 通过 Ring Buffer 将进程信息推送到用户态。

C — 内核态 eBPF 程序 (execmon.bpf.c)
// execmon.bpf.c — 监控进程执行（内核态）
#include "vmlinux.h"           // BTF 生成的完整内核类型定义
#include <bpf/bpf_helpers.h>
#include <bpf/bpf_core_read.h>  // CO-RE 读取宏

// 定义用户态/内核态共享的事件结构体
struct event {
    u32 pid;
    u32 uid;
    char comm[16];      // 进程名
    char filename[128]; // 执行的文件路径
};

// 定义 Ring Buffer Map（用于内核→用户态的事件推送）
struct {
    __uint(type, BPF_MAP_TYPE_RINGBUF);
    __uint(max_entries, 256 * 1024);  // 256KB 缓冲区
} events SEC(".maps");

// 挂载到 sys_enter_execve tracepoint
SEC("tp/syscalls/sys_enter_execve")
int trace_execve(struct trace_event_raw_sys_enter *ctx)
{
    // 在 Ring Buffer 中预留空间
    struct event *e = bpf_ringbuf_reserve(&events, sizeof(*e), 0);
    if (!e) return 0;  // 缓冲区满，放弃本次事件

    // 填充事件数据
    e->pid = bpf_get_current_pid_tgid() >> 32;
    e->uid = bpf_get_current_uid_gid() & 0xFFFFFFFF;
    bpf_get_current_comm(&e->comm, sizeof(e->comm));

    // CO-RE 安全读取：从 ctx 中获取 execve 的文件名参数
    const char *filename_ptr = (const char *)ctx->args[0];
    bpf_probe_read_user_str(e->filename, sizeof(e->filename), filename_ptr);

    // 提交事件到 Ring Buffer（用户态可立即读取）
    bpf_ringbuf_submit(e, 0);
    return 0;
}

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

C — 用户态加载器 (execmon.c)
// execmon.c — 用户态：加载、挂载、读取事件
#include <stdio.h>
#include <signal.h>
#include <bpf/libbpf.h>
#include "execmon.skel.h"    // bpftool gen skeleton 自动生成

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

// Ring Buffer 回调：每当内核提交一个事件时调用
static int handle_event(void *ctx, void *data, size_t len)
{
    struct event *e = data;
    printf("%-8d %-8d %-16s %s\n", e->pid, e->uid, e->comm, e->filename);
    return 0;
}

int main(void)
{
    // ① 打开 & 加载（CO-RE 重定位 + Verifier + JIT 全自动完成）
    struct execmon_bpf *skel = execmon_bpf__open_and_load();
    if (!skel) { fprintf(stderr, "Failed to load BPF\n"); return 1; }

    // ② 挂载到 Hook 点
    if (execmon_bpf__attach(skel)) { fprintf(stderr, "Failed to attach\n"); return 1; }

    // ③ 创建 Ring Buffer 消费者
    struct ring_buffer *rb = ring_buffer__new(
        bpf_map__fd(skel->maps.events), handle_event, NULL, NULL);

    printf("%-8s %-8s %-16s %s\n", "PID", "UID", "COMM", "FILENAME");

    signal(SIGINT, sig_handler);
    while (running)
        ring_buffer__poll(rb, 100);  // 每 100ms 轮询一次

    // ④ 清理（卸载程序、释放 Maps、关闭 fd）
    ring_buffer__free(rb);
    execmon_bpf__destroy(skel);
    return 0;
}

Shell — 编译 & 运行
# 1. 编译 eBPF 程序
$ clang -O2 -target bpf -g -c execmon.bpf.c -o execmon.bpf.o

# 2. 生成 skeleton 头文件
$ bpftool gen skeleton execmon.bpf.o > execmon.skel.h

# 3. 编译用户态程序
$ gcc -o execmon execmon.c -lbpf -lelf -lz

# 4. 运行（需要 root 或 CAP_BPF）
$ sudo ./execmon
PID      UID      COMM             FILENAME
18542    1000     bash             /usr/bin/ls
18543    1000     bash             /usr/bin/grep
18544    0        cron             /usr/sbin/logrotate
18545    33       www-data         /usr/bin/php
^C

---

万物皆有终。当 eBPF 程序完成使命（或不再被需要），它需要被安全地卸载。

Linux 内核通过引用计数（Reference Counting）管理 eBPF 程序的生命周期。 每一个引用——用户态的文件描述符、bpf_link、被其他程序 Tail Call 引用—— 都会将计数加一。当所有引用被关闭，计数归零时， 内核会自动执行清理：

• 解除 Hook：将 Hook 点上的函数指针清空——"收费站"消失，高速公路恢复畅通
• 释放 JIT 代码：回收存放原生机器指令的内核内存
• 销毁 Maps：释放所有关联的 BPF Maps（除非 Map 被其他程序共享或被 pin 到 BPF 文件系统）
• 释放 BTF 信息：回收程序关联的类型元数据

整个过程是优雅且原子的——不会出现"程序卸了一半，Hook 还在"的不一致状态。 这也是为什么 eBPF 适合生产环境的重要原因之一：你可以安全地热更新—— 先加载新版本程序，通过 bpf_link 原子替换旧版本，旧版本引用归零后自动清理。 全程零中断、零数据包丢失。

Shell — 查看引用计数与清理
# 查看程序当前引用
$ bpftool prog show id 42
42: tracepoint  name trace_execve
     ref_cnt 2            // 两个引用：一个 fd + 一个 bpf_link
     loaded_at 2026-04-07T14:30+0900

# 关闭 loader 进程后（fd 释放），如果 bpf_link 未 pin：
$ bpftool prog show id 42
Error: get by id (42): No such file or directory  // 已自动清理 ✓

# 如果 bpf_link 已 pin 到 /sys/fs/bpf/，需要手动 unpin：
$ rm /sys/fs/bpf/my_xdp_link
# 引用归零 → 内核自动清理程序和 Maps

---

任何技术的真正力量不仅在于其原理的精妙，更在于生态系统的繁荣。 eBPF 之所以能从学术研究走向全球基础设施的核心， 是因为一个由开源项目、商业公司和全球巨头共同构建的正向飞轮正在加速旋转。

5.1 开源生态：eBPF 的四大天王

---

5.2 Isovalent 的工业化贡献：从开源到企业级平台

在 eBPF 生态中，Isovalent 扮演着独特且关键的角色。 它不仅是 Cilium 和 Tetragon 的主要创建者和维护者， 更是推动 eBPF 从"内核开发者的工具"走向"企业级基础设施"的核心力量。

Cisco 收购的战略意义（2024）

2024 年初，Cisco 完成了对 Isovalent 的收购—— 这是网络与安全行业过去十年中最具前瞻性的技术并购之一。 其战略逻辑清晰可见：

根据 2025 年 Kubernetes 网络报告，60.8% 的受访者正在使用 Cilium/Isovalent 作为其 CNI——远超第二名。这个数字背后是 eBPF 技术选择的胜利， 也是 Isovalent 长期开源投入的回报。

---

5.3 全球巨头实战：eBPF 在生产中的规模验证

eBPF 已经不是实验室技术——它正在全球最大的基础设施中运行， 每天处理着数万亿个事件。以下是最具代表性的部署案例：

你已经走完了一段不平凡的旅程。

从第一性原理出发，你理解了为什么操作系统内核需要一种安全的可编程机制； 你掌握了 eBPF 是什么——内核中的 JavaScript； 你跟随一个 eBPF 程序走完了它从 C 源码到内核执行再到卸载的完整生命周期—— 编写、编译（BTF + CO-RE）、验证（Verifier 的有界 DFS + 状态剪枝）、 加速（JIT 零开销映射）、挂钩（好莱坞原则 → IoC → 事件驱动）、 运行（零 Context Switch）、通信（Ring Buffer）、终结（引用计数自动清理）； 你看到了 eBPF 在安全、可观测性和网络三大领域引发的范式颠覆； 你了解了从 Google 到 Meta 到 Cloudflare 的全球规模验证； 你探索了 Netkit、sched_ext 和 LLM 可观测性等2026 前沿。

更重要的是，你理解了为什么"The Hard Way"如此艰难—— 以及为什么 Isovalent/Cisco 的 Cilium 和 Tetragon 是将 eBPF 超能力转化为可落地的企业级方案的必经之路。

🐝 eBPF 三部曲导航

---

❓ 常见问题（FAQ）

---

📖 术语表

---

📚 参考资料

---