2. eBPF 基础：发展史、核心架构及与内核模块的对比
2.1 eBPF 发展史：从网络监控到通用内核可编程
eBPF（extended Berkeley Packet Filter）起源于 1992 年由 Steven McCanne 和 Van Jacobson 在 BSD 系统上提出的 BPF（Berkeley Packet Filter）。BPF 最初的设计目标是在内核空间高效过滤网络数据包，避免将无用数据包拷贝到用户态。其核心是一个基于寄存器的虚拟机，运行简单的字节码指令。
2014 年，Alexei Starovoitov 将 BPF 引入 Linux 内核，并进行了革命性的扩展，形成了今天的 eBPF。eBPF 不再局限于网络包过滤，而是演变为一个通用的内核沙箱运行环境，允许用户在不修改内核源码或加载内核模块的情况下，安全高效地注入自定义程序。
| 时间 | 里程碑 | 核心变化 |
|---|---|---|
| 1992 | BPF 诞生 | BSD 系统上的网络包过滤，cBPF（classic BPF） |
| 2014 | eBPF 引入 Linux | 寄存器从 2 个扩展到 10 个，增加 Maps、Helpers，支持 JIT 编译 |
| 2015 | tc（traffic control）支持 eBPF | eBPF 程序可附加到网络数据路径，实现高性能网络处理 |
| 2016 | Tracepoints & kprobes 支持 | eBPF 从网络扩展到可观测性领域，可动态跟踪内核函数 |
| 2018 | BPF CO-RE（Compile Once – Run Everywhere） | 解决 eBPF 程序在不同内核版本间的移植性问题，BCC 工具集成熟 |
| 2020+ | eBPF 成为基础设施标准 | 广泛用于 Cilium、Falco、Pixie 等云原生项目，成为可观测性、安全、网络的核心技术 |
2.2 eBPF 核心架构：五大支柱
eBPF 的架构设计围绕“安全”与“高效”两个核心目标。其运行流程可概括为：用户态编写 eBPF 程序（C/Rust） → LLVM 编译为 BPF 字节码 → 通过 bpf() 系统调用加载到内核 → Verifier 校验 → JIT 编译为本地机器码 → 附加到事件钩子（Hook）执行。
2.2.1 Verifier（校验器）
Verifier 是 eBPF 安全性的第一道防线。它会在程序加载时静态分析 BPF 字节码，确保程序不会导致内核崩溃或产生安全漏洞。Verifier 主要检查：
- 循环终止性： 禁止无限循环，只允许有界循环（循环次数必须在编译期确定）。
- 指针安全： 禁止解引用未初始化的指针、越界访问栈或 Maps。
- 栈大小： eBPF 程序栈空间限制为 512 字节，Verifier 确保不溢出。
- 类型匹配： 确保 Helper 函数参数类型与传入值一致。
2.2.2 JIT（Just-In-Time 编译器）
JIT 编译器将 BPF 字节码转换为目标 CPU 架构（x86_64、ARM64、RISC-V 等）的本地机器码。这消除了字节码解释执行的开销，使 eBPF 程序达到接近原生内核代码的执行效率。对于不支持 JIT 的架构，内核会使用一个解释器作为回退方案。
2.2.3 Maps（数据结构）
Maps 是 eBPF 程序与用户态程序之间共享数据的关键机制。它们是一系列内核态的高性能键值存储结构，支持多种类型：
| Map 类型 | 用途 | 典型场景 |
|---|---|---|
| BPF_MAP_TYPE_HASH | 通用哈希表 | 存储连接跟踪表、进程统计 |
| BPF_MAP_TYPE_ARRAY | 固定大小数组 | CPU 核心计数器、per-CPU 统计 |
| BPF_MAP_TYPE_PERF_EVENT_ARRAY | 高性能事件传递 | 将内核事件批量发送到用户态 |
| BPF_MAP_TYPE_RINGBUF | 环形缓冲区 | 替代 perf_event_array，更高效的数据传输 |
| BPF_MAP_TYPE_LRU_HASH | LRU 淘汰哈希表 | 限制大小的连接缓存 |
2.2.4 Helpers（辅助函数）
eBPF 程序不能直接调用内核函数，必须通过内核提供的 Helper 函数与内核交互。Helpers 提供了安全可控的接口，用于获取上下文信息、操作 Maps、输出日志等。常见的 Helpers 包括：
bpf_get_current_pid_tgid()— 获取当前进程的 PID 和 TGID。bpf_get_smp_processor_id()— 获取当前 CPU 核心 ID。bpf_trace_printk()— 向 /sys/kernel/debug/tracing/trace_pipe 输出调试信息。bpf_map_lookup_elem() / bpf_map_update_elem()— 操作 Maps 数据。bpf_skb_load_bytes() / bpf_skb_store_bytes()— 读取/修改网络数据包内容。
2.3 eBPF 与内核模块的对比
在 eBPF 出现之前，内核模块是扩展内核功能的唯一方式。两者都能在内核空间执行代码，但在安全性、开发效率、可移植性等方面存在显著差异。
| 对比维度 | eBPF 程序 | 内核模块 |
|---|---|---|
| 安全性 | Verifier 静态校验，禁止危险操作，不会导致内核崩溃 | 无安全校验，错误代码可直接导致内核 panic 或内存损坏 |
| 开发效率 | 使用 C/Rust 编写，LLVM 编译，BCC/libbpf 工具链成熟 | 需要深入理解内核 API、内存管理、并发模型，开发周期长 |
| 可移植性 | CO-RE 技术 + BTF 信息，一次编译可在不同内核版本运行 | 必须针对特定内核版本编译，升级内核需重新编译模块 |
| 性能 | JIT 编译为本地码，接近原生性能；但受限于栈大小和 Helper 调用 | 直接调用内核函数，无额外开销，性能上限更高 |
| 功能范围 | 受限：不能任意调用内核函数，不能使用全局变量，不能阻塞 | 无限制：可访问任意内核符号、数据结构、硬件资源 |
| 部署与更新 | 热加载，无需重启系统或服务，更新程序对业务影响极小 | 热加载支持，但卸载不当可能引发内核问题；通常需要重启 |
| 典型场景 | 可观测性（追踪、性能分析）、网络（XDP、tc）、安全（Falco） | 设备驱动、文件系统、硬件虚拟化、需要深度内核集成的功能 |