1. eBPF 基础：发展历史、核心架构与内核模块对比
1.1 eBPF 发展历史：从 BPF 到通用内核可编程
eBPF（extended Berkeley Packet Filter）起源于 1992 年由 Steven McCanne 和 Van Jacobson 在 Lawrence Berkeley Laboratory 开发的 BPF（Berkeley Packet Filter）。BPF 最初设计用于在用户空间高效捕获和过滤网络数据包，其核心是一个基于寄存器的虚拟机，运行在 BSD 内核中。
关键里程碑如下：
| 时间 | 事件 | 核心贡献 |
|---|---|---|
| 1992 | BPF 诞生 | McCanne & Jacobson 提出，用于网络包过滤 |
| 1997 | Linux 内核引入 BPF | tcpdump 等工具依赖 BPF 实现 |
| 2014 | eBPF 合并入 Linux 主线（v3.18） | Alexei Starovoitov 主导，扩展寄存器至 10 个，增加 64 位支持 |
| 2016 | BPF 编译器集合（bcc）发布 | 提供 Python/Lua 前端，降低 eBPF 编程门槛 |
| 2018 | BPF CO-RE（Compile Once – Run Everywhere） | 解决内核数据结构差异，实现跨内核版本兼容 |
| 2020+ | eBPF 成为云原生基础设施核心 | Cilium、Falco、Pixie 等生产级项目广泛采用 |
课程要点： eBPF 已从单纯的网络包过滤工具演变为 Linux 内核的“可编程沙箱”，允许用户在不修改内核源码或加载内核模块的前提下，安全地注入自定义逻辑。
1.2 eBPF 核心架构：Verifier、JIT 与 Maps
eBPF 架构由三个核心组件构成，它们共同保证了程序的安全性、高性能和灵活性。下图展示了 eBPF 程序从加载到执行的完整流程。
1.2.1 Verifier（校验器）
Verifier 是 eBPF 的安全基石。它在程序加载时执行静态分析，确保程序不会破坏内核稳定性。Verifier 执行以下检查：
- 控制流完整性： 确保程序不会进入无限循环（允许有界循环，且循环次数必须在编译期可确定）。
- 栈边界检查： eBPF 栈大小固定为 512 字节，Verifier 确保所有栈访问不越界。
- 指针类型安全： 禁止对未验证的指针进行算术运算，防止内核内存泄漏。
- 辅助函数白名单： 程序只能调用内核预定义的辅助函数（helper functions），不能直接调用任意内核函数。
1.2.2 JIT Compiler（即时编译器）
JIT 编译器将 eBPF 字节码（BPF 指令集）转换为目标 CPU 架构的本地机器指令。这一步骤消除了传统 BPF 的解释执行开销，使 eBPF 程序达到接近原生内核代码的执行速度。目前 Linux 支持 x86_64、ARM64、s390x、RISC-V 等主流架构的 JIT 编译。
1.2.3 Maps（数据结构）
Maps 是 eBPF 程序与用户空间程序之间共享数据的关键机制。Maps 支持多种数据结构，用于不同的场景：
| Map 类型 | 数据结构 | 典型用途 |
|---|---|---|
| BPF_MAP_TYPE_HASH | 哈希表 | 键值对存储，如连接跟踪表 |
| BPF_MAP_TYPE_ARRAY | 数组 | 固定大小计数器、统计信息 |
| BPF_MAP_TYPE_PERCPU_HASH | 每 CPU 哈希表 | 无锁并发统计，减少缓存抖动 |
| BPF_MAP_TYPE_RINGBUF | 环形缓冲区 | 高效事件流传输，替代 perf_event |
| BPF_MAP_TYPE_STACK_TRACE | 栈跟踪 | 性能分析中的调用栈记录 |
1.3 eBPF 与内核模块的对比优势
在 eBPF 出现之前，内核模块（Kernel Module）是实现内核级功能的唯一方式。eBPF 在安全性、开发效率和可维护性方面具有显著优势。下表从多个维度进行对比：
| 对比维度 | eBPF 程序 | 内核模块 |
|---|---|---|
| 安全性 | Verifier 静态检查，禁止危险操作；程序崩溃不会影响内核 | 任何内存错误都可能导致内核 panic 或安全漏洞 |
| 开发门槛 | 使用受限的 C 子集或高级语言（如 Rust for eBPF），有安全边界 | 需要完整内核编程知识，容易引入竞态条件和内存泄漏 |
| 部署方式 | 用户空间加载，无需重启或重新编译内核 | 需要 root 权限加载/卸载，版本依赖强，易导致内核版本锁定 |
| 性能 | JIT 编译后接近原生；无上下文切换开销 | 原生性能，但模块间通信可能引入额外开销 |
| 可移植性 | CO-RE 机制支持跨内核版本运行 | 必须针对特定内核版本编译，升级内核需重新编译模块 |
| 内核接口 | 只能调用预定义的辅助函数（约 200+ 个） | 可以调用任意内核导出函数和宏 |
| 资源限制 | 栈 512 字节，指令数上限 100 万条（可扩展） | 无硬性限制，但需自行管理内存 |
生产环境选择建议： 对于网络监控、安全审计、性能追踪等场景，优先选择 eBPF。对于需要深度修改内核调度器、文件系统或设备驱动的场景，内核模块仍是必要选择。在 Kubernetes 租户隔离场景中，eBPF 的沙箱特性使其成为流量可视化的首选技术。
1.4 eBPF 程序生命周期与事件挂载点
eBPF 程序通过挂载到内核事件点来触发执行。常见的事件挂载点包括：
- kprobes/kretprobes： 动态插桩到任意内核函数入口/返回点，用于调试和性能分析。
- tracepoints： 内核预定义的静态跟踪点，稳定性优于 kprobes。
- XDP（eXpress Data Path）： 在网络驱动层处理数据包，实现高性能包过滤和转发。
- TC（Traffic Control）： 在网络协议栈的 ingress/egress 路径上处理数据包。
- perf_events： 与性能计数器（PMC）结合，用于 CPU 性能分析。
下图展示了 eBPF 程序在内核中的典型挂载位置：