eBPF 基础：发展历史、核心架构与内核模块对比
2.1 eBPF 发展历史
eBPF（extended Berkeley Packet Filter）起源于 1992 年由 Steven McCanne 和 Van Jacobson 在 Lawrence Berkeley Laboratory 开发的 BPF（Berkeley Packet Filter）。BPF 最初设计用于网络数据包过滤，通过在内核中运行一个简单的虚拟机，避免了将数据包从内核拷贝到用户空间再过滤的低效路径。
2014 年，Alexei Starovoitov 将 BPF 扩展为 eBPF，并合并到 Linux 内核 3.18 版本。eBPF 不再局限于网络包过滤，而是演变为一个通用的内核沙箱运行时，允许用户在不修改内核源码或加载内核模块的情况下，安全地注入并运行用户定义的程序。
| 时间 | 版本 | 里程碑 |
|---|---|---|
| 1992 | — | BPF 诞生，用于 tcpdump 包过滤 |
| 2014 | Linux 3.18 | eBPF 合并入主线内核，引入 bpf() 系统调用 |
| 2015 | Linux 4.1 | BPF 映射（Map）机制正式支持 |
| 2016 | Linux 4.4 | JIT 编译器默认开启，性能大幅提升 |
| 2017 | Linux 4.9 | BPF 跟踪（tracing）与性能事件支持 |
| 2018 | Linux 4.15 | BPF 程序类型扩展至 XDP、流量控制等 |
| 2020+ | Linux 5.x | BPF CO-RE（一次编译，到处运行）、BPF 迭代器、BPF 链路 |
关键认知： eBPF 的演进本质是从“网络包过滤器”到“内核可编程沙箱”的质变。对于平台门户的资源配额校准场景，eBPF 的跟踪与映射能力是核心驱动力。
2.2 eBPF 核心架构
eBPF 架构由三个核心组件构成：内核验证器（Verifier）、JIT 编译器和BPF 映射（Map）。三者协同工作，确保 eBPF 程序在内核中安全、高效地运行。
2.2.1 内核验证器（Verifier）
验证器是 eBPF 安全性的基石。它在 eBPF 程序加载到内核时，对 BPF 字节码进行严格的静态分析，确保程序不会破坏内核稳定性。
- 控制流完整性： 验证器构建程序的控制流图（CFG），确保所有路径都是可达的，且不存在死循环或不可达代码。
- 内存安全： 检查所有内存访问是否在合法范围内，禁止越界读写、空指针解引用。
- 指令限制： eBPF 程序最大指令数默认为 4096（可调），防止恶意或失控程序消耗过多 CPU。
- 类型安全： 确保寄存器类型在程序执行过程中保持一致，禁止类型混淆。
注意： 验证器拒绝任何无法证明安全的程序。在平台门户的资源配额校准场景中，如果 eBPF 程序逻辑过于复杂（如包含大量条件分支），可能触发验证器拒绝加载。此时需要简化程序逻辑或使用 BPF 辅助函数。
2.2.2 JIT 编译器（Just-In-Time Compiler）
JIT 编译器将 BPF 字节码转换为目标 CPU 的原生机器码，从而消除解释执行的开销。对于 x86_64、ARM64、RISC-V 等主流架构，eBPF JIT 编译器已经高度优化。
- 性能提升： JIT 编译后的 eBPF 程序执行速度接近原生内核代码，通常比解释执行快 3-5 倍。
- 按需编译： 程序加载时一次性编译，后续调用直接执行机器码，无运行时编译开销。
- 可关闭： 通过内核参数
net.core.bpf_jit_enable可控制 JIT 开关（0=关闭，1=开启，2=调试模式）。
2.2.3 BPF 映射（Map）
BPF 映射是 eBPF 程序与用户空间程序之间共享数据的核心机制。映射类型决定了数据的组织方式和访问语义。
| 映射类型 | 数据结构 | 典型用途 |
|---|---|---|
| BPF_MAP_TYPE_HASH | 哈希表 | 键值存储，如进程 PID → 资源使用量 |
| BPF_MAP_TYPE_ARRAY | 数组 | 固定大小索引，如 CPU 核心 → 计数器 |
| BPF_MAP_TYPE_PERCPU_HASH | 每 CPU 哈希 | 无锁统计，减少缓存争用 |
| BPF_MAP_TYPE_RINGBUF | 环形缓冲区 | 高效事件流传输，如系统调用日志 |
| BPF_MAP_TYPE_STACK | 栈 | 后进先出，如调用栈跟踪 |
| BPF_MAP_TYPE_QUEUE | 队列 | 先进先出，如任务调度事件 |
2.3 eBPF 与内核模块的对比
在 eBPF 出现之前，内核模块是扩展内核功能的唯一标准方式。两者都能在内核空间执行代码，但在安全性、开发效率、可移植性和性能方面存在显著差异。
| 对比维度 | eBPF | 内核模块 |
|---|---|---|
| 安全性 | 验证器保证安全，崩溃风险极低 | 无保护，Bug 可导致内核 panic |
| 开发效率 | 用户态工具链，快速迭代 | 需编译内核头文件，调试困难 |
| 可移植性 | CO-RE 支持跨内核版本运行 | 严格绑定内核版本和配置 |
| 性能 | JIT 编译后接近原生，但指令受限 | 完全原生性能，无指令限制 |
| 功能范围 | 受限的辅助函数和上下文 | 可调用任意内核函数 |
| 部署复杂度 | 低，用户态加载即可 | 高，需编译、签名、分发 |
| 适用场景 | 观测、跟踪、过滤、限速 | 设备驱动、文件系统、调度器 |
平台门户实践建议： 对于资源配额校准场景，推荐优先使用 eBPF。其安全沙箱特性允许在共享内核环境中安全地采集每个容器的 CPU、内存、I/O 数据，而无需为每个内核版本维护独立的内核模块。仅在需要修改内核数据结构或调用未导出内核函数时，才考虑内核模块方案。