1. eBPF 技术概述：起源、发展、核心架构与工作原理

1.1 起源与发展历程

eBPF（extended Berkeley Packet Filter）起源于 1992 年由 Steven McCanne 和 Van Jacobson 在 Lawrence Berkeley Laboratory 开发的 BPF（Berkeley Packet Filter）。最初的 BPF 是一种用于网络数据包过滤的虚拟机，通过在用户空间编写过滤表达式，在内核空间高效执行，显著提升了 tcpdump 等工具的性能。

2014 年，Alexei Starovoitov 将 BPF 扩展为 eBPF，并合并到 Linux 内核 3.18 版本中。eBPF 不再局限于网络数据包过滤，而是演变为一个通用的内核沙箱运行时，允许用户在不修改内核源码或加载内核模块的情况下，安全地注入并运行自定义程序。

时间 版本/事件 里程碑
1992 BPF 诞生 经典 BPF，用于网络包过滤（tcpdump）
2014 Linux 3.18 eBPF 合并入主线内核，引入 bpf() 系统调用
2015 Linux 4.1 kprobe/uprobe 支持，eBPF 可跟踪内核和用户函数
2016 Linux 4.9 XDP（eXpress Data Path）合并，高性能网络数据面
2017 Linux 4.15 BPF 跟踪（tracepoint、perf_event）全面可用
2019 Linux 5.2 BPF CO-RE（Compile Once – Run Everywhere）支持
2020+ Linux 5.x/6.x BPF 调度器、BPF 存储、BPF 安全策略等扩展
关键认知： eBPF 不是 BPF 的简单升级，而是一次架构重构。它将 BPF 从 2 条指令的寄存器虚拟机扩展为 10 条指令的 64 位寄存器虚拟机，并引入了 Map 数据结构、辅助函数、JIT 编译器和 BPF 验证器，使其成为内核可编程的基石。

1.2 核心架构

eBPF 的核心架构由三个主要组件构成：用户空间工具链、内核运行时和辅助基础设施。下图展示了 eBPF 程序从编写到加载、执行的整体流程与组件关系。

eBPF 核心架构图 eBPF 核心架构与工作流程 用户空间 C / Rust 源码 LLVM / Clang 编译 BPF 字节码 (.o) 加载器 (ip / bpftool / libbpf) 内核空间 BPF 验证器 安全沙箱检查 JIT 编译器 本地机器码生成 BPF 运行时 寄存器虚拟机执行 BPF Map 数据交换 事件钩子：kprobe / tracepoint / XDP / perf_event / cgroup / sockops eBPF 程序通过事件驱动执行，不修改内核源码，不加载内核模块，保证安全性与稳定性
架构要点：
  • 用户空间工具链：开发者使用 C/Rust 编写 eBPF 程序，通过 LLVM/Clang 编译为 BPF 字节码，再由加载器（如 ip、bpftool、libbpf）通过 bpf() 系统调用注入内核。
  • 内核验证器：在加载时对字节码进行静态分析，确保程序无循环、无越界访问、无死锁，保证内核安全。
  • JIT 编译器：将 BPF 字节码即时编译为本地机器指令，提升执行效率。
  • BPF Map：内核与用户空间共享的数据结构，支持键值对、数组、哈希表、队列等类型，用于状态传递和事件通知。
  • 事件钩子：eBPF 程序挂载到内核事件点（如系统调用、网络包到达、函数入口/出口），由事件触发执行。

1.3 工作原理

eBPF 的工作原理可以概括为三个核心阶段：编译与加载、验证与编译、事件驱动执行。下面通过一个典型的 eBPF 程序生命周期来详细说明。

阶段一：编译与加载

  1. 开发者编写 eBPF 程序（C 语言），使用 __section 宏指定挂载点。
  2. LLVM/Clang 后端将 C 代码编译为 eBPF 字节码（ELF 格式 .o 文件）。
  3. 用户空间加载器（如 libbpf）读取 ELF 文件，解析 section 和 relocation 信息。
  4. 加载器通过 bpf(BPF_PROG_LOAD, ...) 系统调用将字节码送入内核。
// 示例：一个简单的 eBPF 程序，统计系统调用次数
__section("kprobe/sys_execve")
int sys_execve_entry(struct pt_regs *ctx) {
    u64 key = 0;
    u64 *count = bpf_map_lookup_elem(&execve_count, &key);
    if (count) {
        __sync_fetch_and_add(count, 1);
    }
    return 0;
}

阶段二：验证与编译

  1. 验证器（Verifier） 对字节码进行深度优先遍历，检查：
    • 程序是否有界（无循环或循环次数可预测）
    • 所有内存访问是否在合法范围内
    • 辅助函数调用是否合规
    • 栈大小是否在 512 字节限制内
  2. 验证通过后，JIT 编译器 将字节码转换为当前 CPU 架构的本地指令（x86_64、ARM64 等）。
  3. 如果 JIT 不可用，内核使用解释器执行字节码（性能较低）。
验证器限制： eBPF 程序不允许包含不可达代码、循环（除非使用 bounded loop）、内核函数调用（仅允许辅助函数）、全局变量。这些限制是 eBPF 安全性的核心保障，但也增加了复杂程序的编写难度。CO-RE（Compile Once – Run Everywhere）技术通过 BTF（BPF Type Format）和重定位机制，部分缓解了跨内核版本兼容性问题。

阶段三：事件驱动执行

  1. 加载后的 eBPF 程序被附加到指定的事件钩子（如 kprobe、tracepoint、XDP）。
  2. 当事件发生时，内核自动调用 eBPF 程序，传入上下文（如寄存器状态、网络包数据）。
  3. 程序执行期间，可以通过辅助函数读取/写入 BPF Map，或调用内核提供的其他辅助功能（如获取当前 PID、打印日志）。
  4. 程序执行完毕后，结果存储在 BPF Map 中，用户空间程序通过 bpf(BPF_MAP_LOOKUP_ELEM, ...) 读取。

1.4 核心能力与应用场景

能力领域 典型技术 应用场景
网络 XDP、TC、sockops DDoS 防护、负载均衡、容器网络策略、流量镜像
可观测性 kprobe、uprobe、tracepoint、perf_event 性能剖析、延迟追踪、错误监控、分布式 tracing
安全 LSM BPF、seccomp 运行时安全策略、文件完整性监控、进程行为审计
调度与存储 sched_ext、BPF 存储 自定义 CPU 调度器、内核态缓存策略
DevOps 视角： eBPF 使得在不重启内核、不修改代码、不侵入应用的情况下，实现深度系统监控和策略执行。在 CI/CD 流水线中，eBPF 程序可以作为“基础设施即代码”的一部分，通过模板制品库进行版本管理、自动化测试和灰度发布，这正是本课程的核心实践方向。
← 上一章 📖 返回目录 下一章 →