Mdr-C-Tutorial

B.1 eBPF 概览：历史、架构与应用场景 ​

在复杂的生产环境中，工程师时常需要面对一系列发生在内核幽微处的系统行为。比如某个后台常驻服务每隔数秒就会重新加载一次 /etc/myapp/limits.conf，相关配置一旦在磁盘上变更便立刻生效，然而翻遍整个应用的业务日志，却根本查不出到底是哪个工作线程发起了读取、具体的路径解析耗时多少、在此期间是否伴随异常的文件查找失败。要想精确还原这一连串动作，最直接的技术手段莫过于在虚拟文件系统的 openat 系统调用入口处植入一段动态记录逻辑。然而在传统的系统软件开发路径中，直接修改内核源码并打补丁需要经历漫长的新内核编译、安装与宿主机重启，随后还得在整个软件生命周期中背负维护私有分支的沉重债务；编写并加载内核模块虽然省去了重启的繁琐，但模块代码直接运行在最高特权环（Ring 0），缺乏内存安全沙箱的防护，哪怕是一次偶发的空指针解引用或边界计算疏漏，都有可能瞬间造成整机崩溃宕机。更为麻烦的是，内核模块通常死死绑定特定内核版本的内部数据结构符号，一旦底层发行版内核升级，整套模块就必须重新编译甚至修改适配。

eBPF（extended Berkeley Packet Filter）为现代系统编程开辟了一条全新的道路。它允许我们将特定的逻辑编写为受限的 C 语言程序，由编译器生成规范的机器指令字节码，随后在用户态将其通过系统调用递交至内核内部。在这些字节码被允许执行之前，内核内置的验证器（verifier）会对其执行全路径的静态数学证明，严格杜绝内存越界访问、死锁隐患与未初始化读写，并限定其仅能调用经过内核安全审核的辅助函数（helper function）。验证一旦通过，内核的即时编译器（JIT）便会将其直接翻译为与宿主机架构高度吻合的原生机器指令，挂接至指定的静态或动态钩子（hook）之上。当特定事件在内核中被触发时，程序便在原地极速执行，其产生的数据再经由高吞吐的 BPF 映射（map）通道安全传回用户空间。从最初的包过滤机制到全栈可观测性与安全防护，理解其设计哲学与流水线架构，能够为后续深入探索打下坚实的基础。

1. 给运行中的内核加一段逻辑 ​

当我们在用户态运行的程序需要让内核在底层执行流程中额外附加一段自定义处理逻辑时，从技术实现的维度划分，主要存在三条演进路径。这三条路径在系统工程实践中各有用武之地，其核心差异体现在实现代价、安全边界以及运行时的适用范围上。

1.1 改内核源码 ​

最彻底的办法自然是直接拉取 Linux 内核源码，在虚拟文件系统目录 fs/ 下处理系统调用分发的核心函数内插入相应的观测代码，例如使用 printk 打印调用上下文，随后完成整机内核编译、配置引导项并重启生效。这条路径能够动用内核内部几乎无拘无束的全局符号与私有数据结构，功能上限最高，然而付出的维护代价也最为高昂。针对通用发行版内核，定制化的修改意味着所有配套的软件包都必须重新打包构建；在启用了安全启动（Secure Boot）的物理机环境中，还必须建立一整套受信任的企业自建密钥证书签名链条。更深远的负担在于，这些微小的修改从此变成了一份脱离上游主线的私有分支代码，每逢内核小版本迭代或重大安全补丁发布，工程团队都必须反复经历耗时费力的代码合并、冲突消除与回归测试。这种方式适合为主流内核贡献通用的新子系统或开拓全新的硬件体系支持，若仅是为了在线上环境排查偶发的性能故障或临时探查运行状态，这种重型的流程显然无法满足敏捷诊断的工程诉求。

1.2 写内核模块 ​

可加载内核模块（Loadable Kernel Module，LKM）在灵活性上向前迈进了一大步。借助 insmod 或 modprobe 机制，开发者可以在操作系统保持平稳运行的状态下，将动态编译出的二进制模块即时注入内核地址空间。这种即插即用的特性免去了频繁重启操作系统的巨大代价，成为过去数十年间驱动开发与网络扩展的主流选择。然而，内核模块依然保留了最高特权级别代码的全部弊端：它与内核核心同处于一个没有任何内存隔离与权限沙箱保护的平面地址空间内，一旦模块内部存在细微的逻辑漏洞，诸如野指针解引用、缓冲区溢出或未初始化的栈访问，轻则触发内核 Oops 导致相关进程挂死，重则直接引发 Kernel Panic 造成整个操作系统彻底瘫痪。与此同时，内核模块必须严格针对当前目标内核的头文件与符号版本进行精准编译，内核配置中任何细微的变动、或者内部结构体字段偏移量的微小变迁，都会破坏模块二进制接口（ABI）的兼容性，导致符号校验失败而无法加载。此外，加载内核模块必须持有完全的 root 特权，许多对安全管控极其严格的数据中心还会强制校验模块的发行版官方签名，这使得动态加载第三方内核模块在线上运维中往往受到严格的行政与技术约束。

1.3 用 eBPF ​

eBPF 的诞生为内核可编程性确立了新的范式。开发者将想要注入内核的业务逻辑编写为一个受限的 C 语言函数，交由具备 BPF 后端的现代化 clang/LLVM 编译器编译为一组标准化的虚拟机字节码。用户态的管理程序随后通过专用的 bpf() 系统调用将这串字节码加载至内核。在真正放行这段代码执行之前，内核会启动极为苛刻的验证器程序：验证器会在指令图上遍历所有可能的执行分支，精准模拟每一个通用寄存器的类型流转与数值上下界，确信所有的指针解引用均位于受保护的合法内存边界之内，循环结构必须是有界的，且代码路径必然会在有限时间内抵达出口退出。任何存在安全瑕疵或无法被数学证明终止的程序都会被无情拦截在内核大门之外，此时内核会向用户态返回明确的错误状态码，并附带详尽的验证器执行轨迹日志。只有彻底通过全部安全验证的程序，才会被内核内置的 JIT 编译器在内存中直接编译为宿主机的原生机器码，并挂接到预设的内核探针或网络链路钩子上。每当相应的事件被触发，程序便以原生机器码的速度就地运转。

在整套使用体验中，系统既无需重编内核镜像，也无需承担停机重启的服务中断风险，即使开发者在编写逻辑时出现了逻辑错误，最坏的结果也仅仅是被内核验证器在装载期直接驳回，绝不至于波及宿主机核心运行的稳定性。配合现代化的 CO-RE（一次编译、到处运行）机制，同一份编译生成的 BPF 目标二进制文件甚至能够在跨越多个大版本、结构体内存排布各异的不同 Linux 内核之间无缝分发运行，目标机器无需安装笨重的编译器套件与全套内核源码头文件。

1.4 三条路的取舍 ​

考量维度修改内核源码内核模块 (LKM)eBPF
是否需要重编译内核是否否
是否需要重启系统是否否
潜在出错后果编译失败或新内核无法启动引发内核 Oops 或整机 Panic加载期被验证器拒绝，输出诊断日志
与内核版本的偶合度每个上游版本均需重新移植合并高度绑定特定版本头文件与结构体布局依赖 BTF 能够在各内核版本间平滑移植
逻辑表达能力与范围完全无限制完全无限制受限于挂载程序类型与可用辅助函数集合
运行加载特权完全的 root 特权完全的 root 特权，通常强制模块签名root 特权或细分内核能力（如 CAP_BPF）

在具体的工程实践中，评判一项需求究竟应当采用何种技术方案，往往取决于所要做的事情在本质上是否能够抽象为一个纯粹的事件响应模型：我们是否仅仅期望在某个预设的内核关键事件触发时（例如一次系统调用入口、一个网络报文入栈、一次内存页面换入），以低开销就地提取少量上下文数据并沉淀记录，或者根据给定的安全规则对当前操作执行放行、拦截或有限的参数重写？如果答案是肯定的，那么 eBPF 无疑是兼顾敏捷性与安全性的理想选择。反之，如果系统设计的目标在于颠覆性地重构一套全新的物理文件系统、彻底替换 Linux 默认的调度核心逻辑，或者向用户态暴露一个从未有过的全新系统调用接口，那么这些深层次的结构改造仍然属于修改内核源码或开发专用内核模块的职责范畴。eBPF 的威力正建立在其精心设计的安全隔离边界之上：它本质上是一台被安全机制严密约束的内核执行引擎，它的全部能力边界均来源于内核主动开放的钩子与辅助设施，其前沿生态亦伴随着 Linux 内核自身接口的丰富而不断扩展。

多选

与内核模块相比，eBPF 的特点有哪些？

加载前由内核里的验证器检查，不通过就拒绝加载
不需要重编译内核，也不需要重启
可以调用任意一个内核函数
能做的事受程序类型与辅助函数的限制

2. 从 BPF 到 eBPF ​

在现代技术文档中，eBPF 名称前缀的「e」代表扩展（extended），它明确指涉了这项技术是从一套更加古老的内核机制蜕变升级而来的。那套历史基石在如今被统称为经典 BPF（Classic BPF，cBPF）。其最初的设计动机极其单纯且专注：让诸如抓包工具这样的网络程序，能够直接在内核网络协议栈的底层完成数据包的初筛，把无须关心的海量流量就地丢弃，避免无谓的数据拷贝。到了 2024 年，随着 RFC 9669 标准的正式发布，标准委员会认为 eBPF 的应用版图早已远远超越了最初的网络包过滤范畴，因此该缩写在官方定义中被确立为一个独立的专有名词。不过，回顾其在经典 Berkeley Packet Filter 基础上的演化足迹，依然是洞悉其底层虚拟机形态与设计哲学的最佳路径。

2.1 包过滤器：1992 年的 BPF ​

回溯至 1992 年，来自劳伦斯伯克利实验室（Lawrence Berkeley Laboratory）的 Steven McCanne 与 Van Jacobson 共同发表了开创性的论文《The BSD Packet Filter: A New Architecture for User-level Packet Capture》。论文直击当时网络系统性能的核心瓶颈：所有的网络嗅探与报文分析软件均运行在用户空间，操作系统内核必须将网卡接收到的每一个网络数据包完整地从内核缓冲区复制到用户态内存，供应用程序解析协议头部后判断其去留。在高速网络环境下，海量最终被证明毫无分析价值的数据包在内核态与用户态之间频繁穿梭，这种昂贵的内存拷贝与上下文切换瞬间侵占了绝大部分 CPU 算力。两位先驱提出的解决方案是在操作系统内核中构筑一个极度精简的字节码执行引擎，允许用户态在初始化套接字时动态注入一段极小的过滤程序。这段程序直接挂载在内核网络层入口处，针对收到的每一个报文就地展开布尔评估，唯有命中过滤规则的报文才被允许向上拷贝至用户态。论文给出的基准测试数据相当惊艳：得益于专门契合 CPU 寄存器特性的虚拟机指令集设计，新的求值引擎相比当时主流的栈式过滤器快了整整 20 倍，整体处理吞吐甚至比 Sun 系统的网络接口抽头（NIT）高出两个数量级。

这套构想精巧的包过滤引擎，正是早期的 cBPF 虚拟机。为了在内核中保持极低的执行开销与实现复杂度，它的运行上下文极其克制，硬件模型抽象仅包含极少数状态：

寄存器/存储槽功能定位与说明
A32 位通用累加器，用于承载绝大多数算术运算、逻辑判断与立即数载入
X32 位辅助索引寄存器，专门用于相对寻址或间接计算报文偏移
M[]包含 16 个 32 位宽度的内存暂存槽（编号 0～15），用于临时存放中间计算值

在二进制表示上，一条标准的 cBPF 指令被紧凑地编码为 8 个字节，其内部划分为四个字段：op:16, jt:8, jf:8, k:32。其中 op 是 16 位的操作码，定义了具体的操作类型；jt 与 jf 分别代表条件跳转评估为真（Jump True）或为假（Jump False）时向前跳转的指令偏移步长；k 则作为通用操作数，依据具体操作码被解释为内存偏移、跳转目标或立即数。程序在读取网络报文内容时使用 ld、ldh、ldb（分别对应字、半字和单字节的加载），通过 jeq、jgt、jset 等指令实施数值比较，最终借助 ret 返回一个 32 位整数。在套接字过滤语境下，这个返回值的语义非常直观：它代表「应当保留并拷贝至用户态的数据字节数」。若返回 0，意味着当前报文被就地彻底丢弃；若返回一个不小于报文总长度的极大值（如 0xffffffff），则代表整个报文完整放行；若返回值介于两者之间，内核则会将报文就地截断至指定长度后再上传。

在 Linux 内核文档 Documentation/networking/filter.rst 中，收录了一段经典的 cBPF 汇编示例，其功能是专一地放行以太网 ARP 报文：

text
ldh [12]
jne #0x806, drop
ret #-1
drop: ret #0

这段逻辑首先通过 ldh [12] 从以太网数据帧偏移 12 字节的位置加载 2 字节的以太网类型（EtherType）字段。如果该字段不等于 0x806（即标准的 ARP 协议标识），程序便向前跳转至 drop 标号处返回 0 丢弃；若类型相符，则顺利穿透执行 ret #-1（按无符号数解释即 4294967295），将整包放行。若使用内核源码树 tools/bpf/ 下自带的汇编工具 bpf_asm 对上述文本进行编译，终端便会输出对应的指令流：

bash - bpf_asm
text
$ ./bpf_asm foo
4,40 0 0 12,21 0 1 2054,6 0 0 4294967295,6 0 0 0,

开头的数字 4 宣告了当前指令序列的长度，随后紧跟的四组由逗号分隔的十进制四元组，精准还原了每条指令对应的 op jt jf k 结构。第一组 40 0 0 12 对应于 ldh [12]，其中 0x28（十进制 40）代表半字绝对加载操作码，跳转偏移不启用，k 赋值为偏移量 12。第二组 21 0 1 2054 对应条件分支，其中 0x15（十进制 21）是等值比较 jeq 的操作码，常数 2054 即十六进制的 0x806。由于 cBPF 指令集未原生提供独立的不等跳转指令 jne，汇编器通过将 jeq 的真假分支反转来实现等价逻辑：当两者相等时命中真分支，步长 jt=0 表示直接顺序跌落执行下一条指令 ret #-1；一旦不等则命中假分支，步长 jf=1 表示跳过后续的一条指令，直接抵达末尾的 drop: ret #0。最后的两组 6 0 0 4294967295 与 6 0 0 0 则是返回指令的二进制编码，操作码均为 0x06。

这种原始的指令模型至今依然活跃在网络工具的最底层。以著名的网络诊断工具 tcpdump 为例，当我们在命令行中指定 -d 参数时，它会将上层输入的过滤表达式直接翻译为可读的 cBPF 汇编指令；使用 -dd 参数可以将其导出为可以直接内嵌到 C 语言中的数组结构；而 -ddd 参数则直接打印出上述这种无格式的十进制编码流，方便直接灌入内核调试工具 bpf_dbg。平时我们在命令行敲下的诸如 tcp port 22 这样优雅的高阶过滤语法，在沉降至内核底层执行时，都会被忠实地降解为这台小型虚拟机上一行行运转的加载与跳转指令。

2.2 eBPF：同一台机器，换了指令集与用途 ​

随着计算机体系架构全面迈入 64 位时代，经典 cBPF 仅有的两个 32 位寄存器与极度单薄的指令集，在面对愈发复杂的系统观测与深度控制需求时逐渐捉襟见肘。2014 年，Alexei Starovoitov 向 Linux 内核邮件列表提交了一组重大重构补丁，将这台古老的过滤虚拟机从底层全面改造为全新的通用指令集架构，也就是现代意义上的 eBPF。这项工作随 Linux 3.18（2014 年 12 月）的发布被正式合入主线，同时内核首次向用户态暴露了统揽一切的 bpf() 系统调用。这次跨越式的改造不仅拓宽了寄存器位宽，更将底层指令编码彻底重塑为现代 RISC 处理器的工业标准：

机制与维度经典 BPF (cBPF)现代扩展 BPF (eBPF)
寄存器模型A、X 两个 32 位通用寄存器，附带 16 个临时存储槽11 个 64 位原生寄存器 R0～R10，全量支持 32 位子寄存器操作
内存栈空间无独立栈帧，仅能依赖 16 个暂存槽每个程序享有专属的 512 字节局部受限栈空间
指令二进制格式固定 8 字节：op:16, jt:8, jf:8, k:32固定 8 字节：op:8, dst:4, src:4, off:16, imm:32（另支持 16 字节宽立即数指令）
条件分支逻辑每条跳转显式携带真、假两条独立的 8 位偏移路径仅携带单向 16 位相对偏移，跌落路径由顺序指令自然承接
函数调用机制完全不支持调用抽象原生支持 call 指令，可调用内核辅助函数、kfunc 或模块内部子函数
状态共享与通信仅能借由退出码向外部传递单个 32 位整数引入 Map 抽象，支持内核态与用户态双向并发读写的丰富键值结构
核心应用边界早期套接字报文初筛、seccomp 系统调用沙箱系统全栈动态观测、高性能软件定义网络、内核安全访问控制与调度决策

寄存器资源的成倍扩充直接重塑了指令的编码格局。虽然基础指令依然保持了 8 字节的定长格式，但原本占据 16 位的操作码被精炼为 8 位，腾出的空间被拆分为源寄存器（src）与目的寄存器（dst）的 4 位寻址编号。cBPF 原有的双向跳转偏移被彻底解耦为一个统一的 16 位有符号相对偏移量，表达「在条件满足时向前或向后跳转若干条指令」，若条件不满足则自然跌落至下一条指令顺序执行，这在汇编反编译呈现中通常记为 if w1 != w0 goto +0x5。如果逻辑需要双向分流，只需在紧随其后追加一条无条件跳转指令即可。在寄存器调用规约（Calling Convention）方面，eBPF 精准对齐了现代主流 64 位体系（如 System V AMD64 ABI）：R0 专门存放函数返回值，R1 到 R5 用于向被调函数依次传递入参，R6 至 R9 属于跨函数调用由被调方负责保护的保留寄存器，而 R10 则被固化为只读的局部栈帧基址指针。关于这些寄存器的详细约束，在 B.4 节 会深入展开。

在指令系统蜕变的同时，eBPF 程序在内核中能够挂接的位置也如雨后春笋般迅速扩散开来。回顾其核心能力的发布节点，可以清晰地勾勒出这门技术如何一步步成长为现代 Linux 系统的可编程通用基底：

年月内核版本关键里程碑与特性演进
1992 年 12 月—McCanne 与 Jacobson 撰写并发表奠基性的 BPF 论文（1993 年初在 USENIX 会议宣读）
2012 年 7 月3.5seccomp 正式引入 cBPF 实施细粒度系统调用过滤，BPF 首次走出纯网络世界
2014 年 12 月3.18现代 eBPF 指令集架构与全新的 bpf() 系统调用正式并入 Linux 主线内核
2015 年 6 月4.1eBPF 首次获准附加至内核动态探针（kprobe），拉开通用内核追踪与观测的序幕
2016 年 10 月4.8极速数据路径（XDP）正式合入，网络数据包在分配 sk_buff 之前即可被高效处理
2018 年 8 月4.18BTF（BPF 类型格式）与超高速零拷贝套接字 AF_XDP 携手登场
2019 年 9 月5.3内核验证器正式解除完全静态无环的枷锁，全面支持有限次数的有界循环证明
2020 年 1 月5.5BPF 快速蹦床（Trampoline）机制合入，极低开销的 fentry/fexit 函数挂载方案成为可能
2020 年 5 月5.7BPF LSM 正式落地，安全探针得以直接接入 Linux 安全模块（LSM）核心裁决路径
2020 年 8 月5.8革命性的环形缓冲区（BPF Ring Buffer）架构合入，大幅降低了内核向用户态回传事件的损耗
2024 年 11 月6.12可插拔调度框架 sched_ext 首批核心实现并入主线，用户代码得以定制操作系统 CPU 调度策略
更完整的生态与工程里程碑
  • 2011 年 4 月：针对 cBPF 的内核即时编译器（JIT）被引入内核，过滤器告别了纯软件解释执行的时代。
  • 2015 年 8 月：LLVM 3.7 官方合并了由 Alexei 提交的 BPF 架构后端，从此开发者可以直接使用高级语言 C 编写 eBPF 逻辑并生成原生字节码。
  • 2015 年 9 月：BCC（BPF Compiler Collection）开源项目正式启动，提供了利用 Python 脚本在运行时动态编译 BPF 程序的强大工具链。
  • 2016 年 8 月：云原生基础设施 Cilium 正式对外发布，奠定了基于 eBPF 构建下一代微服务网络与安全策略的基础。
  • 2017 年 5 月：Meta（原 Facebook）正式上线自研的 Katran 四层负载均衡平台，凭借纯 XDP 转发承受海量全球流量。
  • 2017 年 9 月：官方命令行调试瑞士军刀 bpftool 正式进入 Linux 内核源码树（tools/bpf/bpftool）。
  • 2018 年 10 月：受到 DTrace 启发的 bpftrace 高阶跟踪语言首发面世，使得单行命令的系统交互式探查变得极其简单。
  • 2020 年 9 月：GCC 编译器套件正式合并 BPF 目标后端支持，打破了 LLVM 工具链在编译前端的长期垄断。
  • 2021 年 5 月：微软正式启动 eBPF for Windows 开源项目，将这套机制引入了 NT 内核生态。
  • 2021 年：由各大工业巨头联合发起的 eBPF 基金会正式在 Linux 基金会旗下成立，协调多方演进。
  • 2024 年 10 月：IETF 正式发布 RFC 9669，BPF 指令集架构历经三十余载打磨，正式成为国际公认的开放标准。

2.3 今天的 BPF ​

在当下的技术交流与文献表达中，若没有特别冠以「经典（Classic）」的前缀，单言 BPF 通常指代的就是功能完备的 eBPF 体系。然而，早期的 cBPF 并未随着架构演进被扫入历史垃圾堆：自内核 3.5 起广泛应用于进程容器安全隔离的 seccomp 机制，其系统调用沙箱策略至今依然完全构建在 cBPF 指令之上；许多基于原始套接字的过滤规则也沿用了 cBPF 的装配接口，Linux 内核会在加载时刻于内部透明地将这串古老的 cBPF 指令即时重写并编译为 eBPF 字节码再行投递执行。在阅读一些既有的底层代码时，区分两者最关键的线索在于加载系统调用与安装方式的不同：凡是调用 setsockopt(..., SO_ATTACH_FILTER, ...) 或发起 seccomp() 安装系统调用过滤器的，其内部载荷必定是 cBPF 指令；而凡是调用专有 bpf() 系统调用分发至各类子模块的，处理的则是一律由现代 eBPF 规范治理的字节码程序。seccomp 过滤器的具体编程实践，将在 B.13 节 展开详述。

单选

今天仍在使用经典 BPF 的机制是哪一个？

XDP
seccomp
kprobe
BPF LSM

3. 架构总览 ​

在深入剖析各项技术细节之前，首先需要在脑海中建立起一个 eBPF 程序从源码文本到最终在内核中运转的完整工程视界。在现代标准工业流程中，这一链路遵循着一条清晰而严密的组装装配线。下面展示的流水线结构，正是后续所有代码示例与工程项目所共享的通用范式。

整个流水线在空间上清晰地切分为用户态与内核态两个半区。内核态代码的编译构建、自动生成 C 语言骨架头文件、以及编写用户态控制逻辑，均在常规的用户空间完成，最终生成的是一个包含 BPF 字节码的通用 ELF 目标文件与一份强类型的辅助接口头文件。随后，用户态程序借助系统调用将目标文件内容送入内核腹地，在这里依次触发静态审查、本机指令即时编译以及探针钩子的绑定。一旦系统内部的真实事件被唤醒，程序便进入零拷贝的高速执行状态，并借由 Map 机制实现跨界的数据沉淀与状态交互。整套流水线的各环节及其在后续各节中的详细剖析如下：

关键阶段核心执行机制与操作深入章节索引
字节码编译clang 编译器将受限 C 代码转化为 BPF 规范指令，SEC 宏将特定函数分派至指定 ELF 节区B.4 节
目标文件沉淀产出标准 ELF64 目标文件，包含程序指令段、.BTF 类型元数据、.BTF.ext 行号与重定位表B.4 节
宿主加载程序用户态进程解析 ELF、预分配内核 Map 对象、依托 BTF 完成 CO-RE 重定位，发起 bpf() 载入请求B.7 节、B.8 节
静态验证证明内核验证器针对所有代码路径推演寄存器状态与数值区间，严格完成内存安全与程序终止性证明B.9 节
原生指令执行内核 JIT 将 BPF 字节码转换为宿主机 CPU 机器码，当绑定的钩子事件被触发时就地运行本节
状态通道共享依托 BPF Map 提供的键值存储与环形缓冲区，实现内核态与用户态的双向高效通信B.6 节
挂载类型协同程序挂载类型决定运行上下文（ctx）的内存排布、可用辅助函数清单及返回值的裁决语义B.10 节

3.1 最小程序：两条指令 ​

为了剥离辅助工具带来的复杂认知负担，我们可以暂时搁置庞大的头文件与骨架结构，直接探查最终被递交给 Linux 内核的核心载荷究竟是怎样的形态。下面展示的代码不依赖于任何外部的第三方头文件，而是直接通过底层宏定义手写 SEC 节属性。该程序的目标极为专一：在操作系统发起 openat 系统调用入口的一瞬间被激活，随后立即向内核返回 0 退出。完整源码归档在 code/系统编程/拓展B_eBPF/B_1_eBPF概览/ret0.bpf.c：

c
/* ret0.bpf.c：本页用来观察 eBPF 指令编码的最小程序。 */
#define SEC(name) __attribute__((section(name), used))

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

SEC("tracepoint/syscalls/sys_enter_openat")
int ret0(void *ctx) {
    (void)ctx;
    return 0;
}

代码中的 SEC 宏实际上展开为编译器内置属性 __attribute__((section(name), used))。它强制指导编译器将当前函数编译生成的机器字节码，放置在目标文件中名为 tracepoint/syscalls/sys_enter_openat 的专有 ELF 节区内；同时 used 属性向编译器表明该函数即使在当前源文件中从未被任何本地代码显式调用，也绝不能被死代码消除（Dead Code Elimination）优化阶段悄然剥离。在 eBPF 的世界里，决定一段代码被内核视作何种程序类型、以及应当被锚定到内核哪个具体探针上的，正是这个被赋予特定命名规范的节区字符串；而 C 语言层面的函数名，主要用于用户态骨架代码中标识并引用特定的程序对象。

接下来我们使用具备 BPF 交叉编译能力的 clang 将其编译为目标二进制，并调用反汇编工具审视其内部构造。这里使用带有 -target bpfel-freestanding-none 或标准 -target bpf 的编译器完成构建，生成的机器指令在各版本 LLVM 之间具备极佳的一致性：

bash - ret0
text
$ clang -g -O2 -target bpf -mcpu=v3 -Wall -Wextra -c ret0.bpf.c -o ret0.bpf.o
$ llvm-objdump -d ret0.bpf.o

ret0.bpf.o:	file format elf64-bpf

Disassembly of section tracepoint/syscalls/sys_enter_openat:

0000000000000000 <ret0>:
       0:	b4 00 00 00 00 00 00 00	w0 = 0x0
       1:	95 00 00 00 00 00 00 00	exit

整段内核态程序在最终编译后仅包含两条指令，总计占用 16 个字节。观察反汇编输出中左侧的十六进制原始字节：第一条指令 b4 00 00 00 00 00 00 00 中，首字节 0xb4 对应于将 32 位立即数写入通用寄存器的操作码；第二字节 0x00 的低 4 位编码了目的寄存器的索引编号 0（即 R0 寄存器）；随后的两个字节为 16 位的相对跳转偏移 0；末尾的四个字节则完整承载了 32 位的常数立即数 0。第二条指令中的 0x95 则是标准的 exit 退出操作码。在 BPF 虚拟机的体系调用规约中，R0 寄存器被严格指定为承载函数返回值的通用载体，因此这两条指令组合起来的严谨语义正是「向返回值寄存器 R0 写入整数 0，随即结束当前执行帧并返回」。

之所以在此处呈现为 w0 = 0x0 的 32 位子寄存器操作，是因为我们在编译参数中显式指定了 -mcpu=v3，这允许编译器在生成指令时自由调度更紧凑高效的 32 位寄存器指令（操作码 0xb4）。如果我们将构建选项退回至最早期的 -mcpu=v1，编译器则会退守至保守的 64 位宽立即数传送指令（操作码 0xb7），对应的反汇编便会呈现为 r0 = 0x0。虽然在这段极其微小的返回逻辑中，两者最终在内核中产生的运行时结果别无二致，但底层机器码编码的真实差异清晰地揭示了编译目标架构版本对最终二进制指令生成的直接影响。

如果进一步使用工具检查生成的目标文件节区头部，可以看到一个结构完整的 ELF 文件轮廓：

bash - llvm-objdump -h
text
$ llvm-objdump -h ret0.bpf.o
ret0.bpf.o:	file format elf64-bpf

Sections:
Idx Name                                 Size     VMA              Type
  2 .text                                00000000 0000000000000000 TEXT
  3 tracepoint/syscalls/sys_enter_openat 00000010 0000000000000000 TEXT
  4 license                              0000000d 0000000000000000 DATA
  9 .BTF                                 0000015a 0000000000000000 
 10 .rel.BTF                             00000010 0000000000000000 
 11 .BTF.ext                             00000050 0000000000000000

节区 tracepoint/syscalls/sys_enter_openat 的长度恰好为 0x10（即 16 个字节），正好完整容纳了上述两条机器指令。名为 license 的数据段内存储了长度为 13 字节的许可证声明字符串 "Dual BSD/GPL"。这个字符串在加载阶段会被 libbpf 抽取并一并呈交给内核，内核验证器会据此判定该程序是否具备调用特定专有 GPL-only 内核辅助函数的法定资质。而 .BTF 与 .BTF.ext 节区则系统地存储了编译期提取出的丰富数据类型定义、函数符号行号映射以及跨内核重定位元数据，它们构成了现代动态加载器与内核验证器执行安全审查与结构体偏移重定位的基准信息。

3.2 加载与附加 ​

单纯静止保存在磁盘上的 ELF 目标文件本身无法在内核中自发运转。必须由一个运行在用户态的宿主管理程序负责打开并解析该 ELF 文件，在内核中创建对应的 Map 数据通道，完成指针与字段偏移的重定位，随后通过 bpf() 系统调用的 BPF_PROG_LOAD 子命令将各个程序指令段依次推送给内核验证器。待全部字节码通过安全审查后，用户态程序再通过特定的接口将程序对象挂载至目标钩子上。为了将这一长串繁杂低级的系统调用流程彻底标准化，官方标准库 libbpf 将整个生命周期封装为了若干直观的 C 语言函数；而专用工具 bpftool gen skeleton 更进一步，能够直接根据已编译的目标文件，逆向反推并自动化生成一份类型高度安全的专属 C 语言头文件，这就是现代 BPF 开发中不可或缺的「代码骨架（Skeleton）」。

当我们使用 bpftool 工具为上述的微型目标文件生成骨架时，可以在头文件中清晰地观察到程序与挂载链路被自动化组织成了强类型的结构体成员：

bash - bpftool gen skeleton
text
$ bpftool gen skeleton ret0.bpf.o
/* SPDX-License-Identifier: (LGPL-2.1 OR BSD-2-Clause) */

/* THIS FILE IS AUTOGENERATED BY BPFTOOL! */
#ifndef __RET0_BPF_SKEL_H__
#define __RET0_BPF_SKEL_H__
...
struct ret0_bpf {
	struct bpf_object_skeleton *skeleton;
	struct bpf_object *obj;
	struct {
		struct bpf_program *ret0;
	} progs;
	struct {
		struct bpf_link *ret0;
	} links;
...
};

在这份骨架契约中，暴露了四组最核心的生命周期管理 API：ret0_bpf__open() 负责在用户空间读取并初验 ELF 结构；ret0_bpf__load() 将解析出的全部对象与 Map 正式载入内核并完成验证；ret0_bpf__attach() 负责将校验通过的程序激活并稳固挂载至内核探针；而 ret0_bpf__destroy() 则在监控结束时负责平稳卸载并回收一切关联的内核与用户态资源。

eBPF 程序的运行方式

eBPF 程序在根本上是纯粹的事件驱动模型：它始终被静态或动态地锚定在某一个预设的内核钩子之上，唯有当系统运行触发了该钩子所代表的底层事件时，代码才会被内核调度执行。若绑定的内核事件从未发生，整段程序在内核中便处于完全静默的状态，不消耗任何 CPU 运算周期。由于在加载阶段内核验证器已经穷尽推演并证明了其完全的安全性，在运行时内核无须对每一条指令开展防御性边界核查，经过 JIT 即时编译生成的原生指令以极高的效率运转，其调用延迟几乎完全等同于内核原生内嵌的静态代码。

在初涉系统可编程机制时，有两个关于执行模型的关键特质极易引起认知混淆，在此有必要展开明确的厘清。

其一，eBPF 程序并不具备独立常驻的系统进程或线程形态。它既不存在任何形式的用户态「主事件循环」，也绝不可能自发地在内核中拉起工作，更无法主动调用常规的睡眠或阻塞等待原语（少数专门标记为可睡眠的 LSM 或跟踪探针除外）。在两次相继触发的事件调用之间，BPF 虚拟机不会保留任何通用寄存器或局部执行栈的历史痕迹，每一次事件触发都是一次完全崭新的调用栈展开。如果业务需要在连续的事件流之间持久化状态、或者完成计数聚合，必须借助独立的 Map 存储通道：Map 是独立于程序指令而驻留在内核内存中的对象，即使挂载的程序被卸载，持有有效引用的 Map 依然平稳存续，用户态程序亦可随时通过文件描述符对其展开并发读写。

其二，「由验证器证明安全」特指的是前置的加载审查，而非在每次运行时重复验证。内核验证器在程序装载期间，会模拟穷举所有可能的分支路径，细致推导每一个寄存器的类型演变与数值动态区间，确保所有的内存寻址都绝对收敛在合法安全边界内，且逻辑必定能够在有限的指令周期内顺利返回。这种深度的全状态证明开销极为高昂，因此内核将其前置并限定仅在装载时刻执行一次。一旦审查通过，JIT 生成的原生指令便可以在内核热路径上肆意飞驰。若在每次事件到来时都需要介入边界校验，eBPF 所引以为傲的近原生处理性能便会荡然无存。

单选

一个附加到 sys_enter_openat 上的 eBPF 程序，什么时候运行？

加载程序启动后立即运行一次，之后每秒运行一次
附加的钩子上有事件发生时运行
用户态程序调用 bpf() 读取 map 时运行
由内核的定时器周期性唤醒

3.3 各部分对应的节 ​

将上述完整开发流水线归纳到具体的代码工程组织中，一个工业级的 eBPF 工具通常由四大类文件协同组成：以 .bpf.c 结尾的代码承载运行在内核空间的核心逻辑；以 .c 结尾的宿主代码承载用户态生命周期管控与数据呈现；由 bpftool 从编译产物逆向提取出的 .skel.h 骨架头文件充当两界之间的强类型链接桥梁；而在两端之间广泛共享的数据结构与枚举常量，则被集中安置在通用的 .h 接口头文件中。全书所有章节的实战案例均严格遵循这一清晰的结构模式进行编排组织。

本拓展的验证方式

将 eBPF 程序成功注入操作系统内核并完成探针挂载通常需要系统管理员（root）级别的管理特权，而在许多自动化测试与沙箱环境中往往受限于权限隔离策略。为了保证教学代码在各种终端环境下的高度可复现性，本拓展教程中的所有内核态程序均通过具备完整 BPF 后端特性的 clang 编译器完成严格的字节码构建，并通过 llvm-objdump 深入印证其节区排布与指令语义；对应的 C 语言骨架代码均经由标准 bpftool 实地生成，而宿主加载程序则全部通过了严苛的语法与类型系统审查。凡是必须在特权环境下激活探针才能捕获的终端运行记录，均与 Linux 内核官方测试用例及 libbpf-bootstrap 权威实现严格对齐，并以规范的命令行会话形式呈现。读者在自己的实验机器或虚拟机上实际载入执行时，诸如进程号（PID）、纳秒级系统时间戳等易变运行时数据自然会呈现出宿主机实时的动态差异。

4. 三类典型应用 ​

在当代系统软件工程中，eBPF 的工业实践主要围绕三大方向展开。这种划分方式不仅在开源生态与主流技术文献中形成了广泛共识，同时也与 Linux 内核内部为 eBPF 划分的程序类型群组形成了紧密的映射关系。

4.1 观测 ​

动态可观测性是 eBPF 目前应用最为广泛、技术成熟度极高的方向，也是本书在系统编程视角下深入探讨的重点领域。操作系统内核在运转过程中，其内部各个核心阶段均蕴藏着丰富的运行状态流转：从系统调用的发起与退出、内核任意函数的调用与返回、网络协议栈报文的收发排队、进程上下文在 CPU 运行队列中的抢占切换，到虚拟文件系统的路径寻址与磁盘块设备 I/O。借由 eBPF 技术，开发者可以在几乎任何关键路径上就地设立探针，无缝截获现场的纳秒级高精时间戳、进程凭证、调用传参及内部状态。更具威力的是，程序可以直接在内核空间完成初步的聚合计算——例如动态维护直方图桶位、统计延迟分布分位数或累加频次——最终仅仅将经过高度压缩的统计指标回传给用户态。

在过去，对系统内部行为的动态探查通常不得不依赖三类具有显著缺陷的传统手段：strace 工具虽然能详尽列出单个进程的系统调用轨迹，但其底层完全依赖 ptrace 机制，每次进入与退出系统调用都需要强制挂起目标进程并经历繁重的进程切换，在生产环境下往往导致服务吞吐断崖式下跌；perf 工具依托 CPU 硬件性能计数器实现定频采样，但它本质上仅能捕获指令指针当前所处的调用栈切片，对于瞬时发生或极为罕见的偶发异常往往无能为力；而在业务源码中打日志则必须提前感知问题并在编译期埋点，面对未知的系统波动显得极度被动。eBPF 完美补齐了这一技术断层：它无须挂起目标业务进程，无须提前侵入源码重新编译，亦不局限于已有的用户态代码空间，使得针对内核几乎全部关键函数与用户态动态链接符号开展低损耗、全方位的动态观测成为现实。

在系统性能分析领域，Brendan Gregg 将 eBPF 的观测生态划分为两个典型层次：以 BCC 为代表的重型框架更适合开发功能完备、长期驻留的系统守护监控进程；而以 bpftrace 为代表的轻量级前端则专注于交互式的一行脚本与临时性故障排查。如今在各类 Linux 发行版中广泛预装的 execsnoop（新进程生命周期感知）、opensnoop（文件打开与访问追踪）、biolatency（块设备 I/O 延迟直方图统计）、tcpretrans（TCP 报文重传原因与连接剖析）等经典工具，彻底重塑了系统运维与故障诊断的日常面貌。这些工具的共同设计哲学，正是坚决将海量高频事件的过滤与聚合下沉至内核执行，仅向用户空间暴露精简的汇总数据，使得即便在内核事件每秒触发数十万次的极限负载下，系统整体引入的性能损耗依然被稳稳压制在几个百分点之内。针对自主开发观测工具的完整实战路径，将在 B.11 节 与 B.15 节 深入剖析，而借助 bpftrace 单行脚本的高效诊断则在 B.14 节 集中展现。

4.2 网络 ​

网络数据面是 eBPF 萌芽并实现技术爆发的最早阵地，其根本原因在于挂载点在网络拓扑中所处的绝佳地理位置。现代 Linux 网络栈中的极速数据路径（eXpress Data Path，XDP）允许开发者将 BPF 程序直接注入网卡驱动层的核心数据环，甚至下沉到网卡硬件固件（SmartNIC）内部执行。在这一位置上，网络硬件刚将数据帧通过 DMA 搬移至主机内存，内核甚至尚未开始为该报文分配庞大复杂的套接字缓冲区结构体（sk_buff）。此时，一段紧凑的 XDP 程序只需直接从原始内存缓冲区中解引用几十个字节的以太网与 IP 协议头，经过几组极速的位运算比对，便可直接向驱动层返回裁决结果：是直接原地丢弃、无损放行，还是直接改写 MAC 地址后通过同一网卡原路反射弹回。Cloudflare 在 2018 年公布的技术实测表明，在单颗普通通用 CPU 核心上，依托 XDP 技术可以在一秒内轻松裁决并丢弃超过一千万个恶意洪泛数据包。这种将过滤前置到极致的能力，构成了当代互联网基础设施抵御海量分布式拒绝服务攻击（DDoS）的核心基石。

超越单纯的数据包拦截，现代云原生系统更进一步将复杂的报文转发与路由决策全量移交至 eBPF。Meta 广泛部署在生产边缘的 Katran 四层负载均衡系统，其核心转发平面便是一组高效运转的 XDP 程序：它在收包时刻查阅内核 Map 维护的一致性哈希转发表，就地挑选出目标后端服务，为原始数据包封装外层隧道报文后直接派发，整个转发路径完全绕过了传统 Linux 协议栈庞杂的流控与路由查找开销。而在微服务容器平台领域，著名开源项目 Cilium 则直接将 eBPF 确立为 Kubernetes 的网络连通、服务发现、精细网络策略与链路观测的统一底层，使得传统的 kube-proxy 组件及其背后规模臃肿、更新缓慢的 iptables 规则链条得以被全量替代。

在使用 C 语言编写这类高性能网络逻辑时，最具挑战性的环节并非协议算法本身，而是内核验证器对报文内存越界访问发起的苛刻审查：在对报文缓冲区的任何字段发起解引用之前，代码必须在控制流中显式包含与报文结尾指针 data_end 的安全边界比对，若有哪怕一个字节的潜在越界可能，验证器都会在装载时刻直接驳回。这套边界防御与报文解析范式将在 B.12 节 进行细致剖析。

4.3 安全 ​

在系统安全防御与访问控制维度，eBPF 的工业实践主要清晰地分化为两大支柱：高精度的全景安全审计，以及低延迟的原生内核拦截。

安全审计的核心诉求在于对操作系统内所有与安全态势紧密关联的敏感行为实施毫无遗漏的沉淀记录。无论是新进程的衍生替换、特权证书的调整、敏感配置文件的读取、高危权限的校验，还是跨主机套接字的建立，都可以在相应的内核探针处挂载 BPF 程序。与过去传统的 Linux Audit 审计子系统相比，eBPF 能够直接深入内核对象的私有字段捕获极其精细的上下文信息，且数据回传通道的性能损耗远低于经过审计管道（auditd）的文本序列化传输。

而在实时防御与策略拦截领域，eBPF 则赋予了管理员在无需重新编译或重启操作系统的动态前提下，重塑内核安全决定的强大能力。BPF LSM 机制允许开发者将自定义的安全程序直接挂载至 Linux 安全模块（Linux Security Module）预设的数百个微观裁决钩子之上。当受控操作发生时，BPF 程序可以就地审查当前的进程凭据与目标对象属性，若返回 0 则代表安全放行，若返回负的错误码（如 -EPERM）则直接在内核底层将该操作强行阻断。其拦截威力等同于就地编写并注入了一条原生的强制访问控制规则，且这套规则随时可以通过用户态命令实现毫秒级的热更新与动态卸载。此外，附加在控制组（cgroup）层级的 BPF 程序能够按容器边界精准约束其内部所有进程的套接字绑定、设备节点访问以及通信端口限制，systemd 服务配置中常见的 SocketBindDeny= 与 DeviceAllow= 选项，其底层正是借由这套机制得以轻量级落地的。

另一项极具代表性的内省防御手段则是针对进程自身的沙箱收紧：安全计算模式（seccomp）。它允许进程在初始化阶段向内核注册一段基于 cBPF 指令集的过滤逻辑，在此之后，该进程及其派生的所有子线程每次发起系统调用，都必须无条件经过这套过滤器的初筛，任何不在白名单内的调用都会被内核就地捕获并向进程派发 SIGSYS 信号甚至就地终止。现代容器运行时（如 containerd、runc）以及主流 Web 浏览器均依托 seccomp 在沙箱内部将数百个不必要的系统调用强行剪枝。seccomp 之所以至今坚决沿用 cBPF 而未迁移至完整的 eBPF，正是因为其输入数据格式高度固定、裁决路径极度短促，无须引入 Map 状态与多级辅助函数的额外开销。关于这三类安全防御机制的工程协同与编写实践，将在 B.13 节 展开系统比对。

4.4 还在长出来的方向 ​

技术的演化从未止步。随着 Linux 6.12 内核的正式发布，可插拔调度子系统 sched_ext 的首批核心实现被正式并入上游主线，这标志着开发者甚至可以使用一组协同工作的 BPF 程序完全替代系统默认的 CFS/EEVDF 调度器：在何时挑选哪个就绪任务、分派到哪个 CPU 核心、如何权衡能耗与抢占时机，全部由用户态注入的 BPF 逻辑即时决策。这不仅打破了长期以来调度器必须固化在内核核心的壁垒，更为针对特定工作负载（如游戏引擎渲染、AI 分布式训练通信）深度定制专属调度策略提供了前所未有的自由度。与此同时，HID-BPF 机制的合入允许工程师针对特定异常的人机交互外设（如键鼠、绘图板）编写专属的数据流修补逻辑，彻底告别了以往为了修复微小的硬件 quirks 就必须向内核驱动源码提交补丁的漫长周期。

这些前沿演进无不印证了一个核心事实：eBPF 的能力边界始终伴随着 Linux 内核对外暴露钩子的广度而持续拓宽。在进行技术架构选型时，评估一项复杂的底层需求能否依托 eBPF 优雅落地，关键就在于审视当前宿主机内核是否已经为该领域预先提供了合法的程序类型定义与功能完备的辅助函数接口。

单选

XDP 程序在收包路径上的位置带来了什么特点？

在网卡驱动刚收到帧、还没有分配 sk_buff 时运行，可以就地丢弃
在应用调用 read() 时运行，可以改写读到的数据
只能处理 TCP，不能处理 UDP
必须配合 iptables 规则才能生效

5. 生态与本章的取舍 ​

5.1 工具链一览 ​

现代 eBPF 生态经过十余年的蓬勃发展，早已告别了手工编写原始汇编的蛮荒时代，形成了层次丰富、涵盖多种主流开发语言的技术选型阵列：

开发工具/框架核心编写语言核心运行机制与工程适用场景
BCCPython 驱动，内核态采用 C适合利用社区现成工具开展性能排查，或编写快速原型脚本验证想法
bpftrace专属高阶脚本语言适合在命令行进行单行即时交互式排查，或编写几十行的敏捷诊断脚本
libbpf原生纯 C 语言库适合开发高性能、自包含、便于跨平台分发且需长期维护的生产级系统工具
cilium/ebpf纯 Go 语言库适合与 Docker、Kubernetes 等既有 Go 语言云原生基础设施深度集成的项目
Aya纯 Rust 工具链前后两端全量基于 Rust 构建，不依赖任何 C 语言工具链或 LLVM 运行时链接
libbpf-rsRust 语言封装绑定在 Rust 系统项目中安全复用官方 libbpf 核心逻辑与 CO-RE 特性

在早期探索中，BCC 框架采用了革命性的运行时动态编译机制：开发者在 Python 脚本内部以内嵌字符串的形式书写内核态 C 代码，当脚本在宿主机启动时，它会在后台动态调用本地的 clang/LLVM 编译器将该字符串即时编译为 BPF 字节码并注入内核。这种模式虽然极大地简化了早期开发者的编码心智模型，然而在生产部署时却暴露出了严峻的短板：目标运行机器必须强制安装 clang、LLVM 编译套件以及全套匹配当前运行内核的头文件包（kernel-headers）。Brendan Gregg 在 2020 年那篇讲 CO-RE 的文章里给出的数字是：这套依赖可以占去 100 MB 以上的存储空间；一旦线上宿主机磁盘空间受限或内核头文件缺失，工具便根本无法启动。

5.2 为什么以 libbpf 加 CO-RE 为主线 ​

现代工业界的工程实践已经全面转向由官方主导的 libbpf 配合 CO-RE 体系。libbpf 将 BPF 程序的完整生命周期拆解为四个条理分明、高度确定的阶段（读取打开、装载校验、探针附加、平稳销毁），彻底剔除了运行时动态编译与笨重的 Python 解释器外壳。同一篇文章里，libbpf 版的标准追踪工具 opensnoop，未剥离时 645 KB，剥离后其最终独立二进制文件仅有 151 KB，并且其运行时完全不依赖 libLLVM 或 libclang 动态库，仅依赖系统的基本 C 库（libc）、libelf 与 libz。如此精简的小型工具在编译完成后，可以直接作为一个普通的静态二进制文件复制到任意目标机器上秒级拉起，只要目标宿主机的内核开启了 BTF 支持即可。

而 CO-RE（一次编译、到处运行，Compile Once – Run Everywhere）机制则彻底攻克了传统系统工具跨版本移植的顽疾。现代 clang 编译器在生成字节码的同时，会将代码中所有对内核结构体字段的成员访问，原原本本地记录为特殊的类型重定位元数据并存入 .BTF.ext 节区。当编译出的单一目标文件被分发至具体的运行节点时，libbpf 会在加载时刻现场读取目标宿主机当前内核暴露的 /sys/kernel/btf/vmlinux 类型定义，根据符号名称与类型定义精准反查该字段在当前特定内核中的实际内存偏移量，并动态修补字节码指令中的内存寻址偏移。这种机制赋予了同一个 .bpf.o 目标二进制跨越不同内核版本、甚至在结构体字段被随意重排与扩展的不同发行版间平滑执行的惊人兼容性。其底层实现机理将在 B.8 节 进行全方位的深度解构。

因此，本拓展教程全篇毫不妥协地将 libbpf 配合 CO-RE 确立为系统级开发的核心技术主线：从 B.3 节 开始的每一个动手案例，均采用「内核态受限 C 配合用户态管理 C」的经典架构，依托 bpftool gen skeleton 自动化提取强类型骨架，借助 pkg-config 规范引入 libbpf 编译配置。而对于 bpftrace，我们在 B.14 节 将其专门定位为敏捷排查的瑞士军刀：如果一个复杂的系统故障能够在生产现场借助一行优雅的命令在数十秒内得出定论，我们便完全没有必要兴师动众为之搭建庞大的工程项目；唯有当监控需求需要复杂的参数解析、需要集成进常驻监控看板、或者需要跨集群分发分发交付时，再遵循标准范式将其沉淀为严谨的 libbpf 工程。

先用 bpftrace 问清楚问题

在面对复杂的线上系统异常时，排查的第一阶段往往需要快速回答诸如「究竟是哪个异常进程在短时间内频繁发起无效连接」「该内核底层函数在峰值时期的每秒调用频次是多少」这类定性问题。在这一阶段，bpftrace 凭借其强大的单行脚本表达力，往往能够在十几秒内为工程师指明方向。待在终端中完全锁定了需要观测的探针锚点、需要提取的关键结构体字段以及精准的过滤条件之后，再从容启动完整的 libbpf 项目工程进行固化实现。这种由浅入深的节奏能够有效避免在排查初期就陷入冗长的工程编译与骨架配置琐碎中，从而让注意力始终聚焦在系统行为本身。

5.3 跨平台 ​

随着体系架构与标准化工作的推进，eBPF 的理论与实践正在稳步跨出传统 Linux 系统的物理疆界。微软于 2021 年正式开源了 eBPF for Windows 项目，其在 Windows 用户空间引入了 PREVAIL 验证器进行静态形式化证明，并将校验通过的字节码安全编译为受内核代码签名机制信任的 NT 驱动程序，同时向开发者提供了与官方 libbpf 高度兼容的 C 语言开发接口。在规范标准化层面，IETF 于 2024 年 10 月正式推出了 RFC 9669《BPF Instruction Set Architecture (ISA)》，将这套通用虚拟机的底层指令编码规范确立为国际通用的标准技术轨道。需要指出的是，该标准当前聚焦规范的是「一段通用的 BPF 字节码在虚拟机层面上应当如何被统一解释与执行」，而具体的内核挂载钩子、专有辅助函数集合以及操作系统底层上下文结构依然高度依赖各宿主内核自身的生态，因此跨平台更多体现在设计范式与源码抽象层面的复用。关于 Windows 平台上的实践形态与差异对比，将在 B.16 节 展开全方位的探索。

6. 习题 ​

6.1 巩固 ​

#46101
⚡1⏳1

本页的最小程序 code/系统编程/拓展B_eBPF/B_1_eBPF概览/ret0.bpf.c 不依赖 libbpf 的头文件也能编译。做三件事：

  1. 分别用 -mcpu=v1 和 -mcpu=v3 编译它，把两份 llvm-objdump -d 的输出贴出来，指出唯一不同的那条指令（本题的实测结果：v1 是 r0 = 0x0，操作码 0xb7；v3 是 w0 = 0x0，操作码 0xb4）；
  2. 按 3.1 节讲的方法，把 b4 00 00 00 00 00 00 00 这 8 个字节拆成 opcode、dst、src、off、imm 五个字段，写出每个字段的值；
  3. 解释为什么返回 0 这条语句在 -mcpu=v3 下编成 w0 = 0x0 而不是 r0 = 0x0；再把返回值改成 0x100000000LL 各编译一次，说明为什么这时两个版本的输出完全一样。
#46102
⚡2⏳1

2.1 节给出了 ARP 过滤器的 cBPF 源码和 bpf_asm 的汇编结果：

text
4,40 0 0 12,21 0 1 2054,6 0 0 4294967295,6 0 0 0,
  1. 逐个字段说明这四条指令各是什么，特别是 21 0 1 2054 里的 21 为什么对应 jeq 而不是 jne，jt=0、jf=1 又分别表示跳到第几条；
  2. 手动执行这四条指令，分别写出以太网类型字段为 0x0806、0x0800、0x86dd 时程序的返回值；
  3. 把源码改成只放行 IPv4 TCP（类型字段 0x0800，IP 协议号在偏移 23，值为 6），按 op jt jf k 的格式写出指令条数与每一条的四个数字，留到 47105 用解释器验证。
#46103
⚡2⏳3

把第 3 节的流水线拆开：指出下面每一项处在哪个环节、由谁执行（用户态工具、内核，还是文件系统里的一份文本）：

  • ret0.bpf.c
  • ret0.bpf.o
  • ret0.skel.h
  • 用户态加载程序里的 ret0_bpf__open()
  • BPF_PROG_LOAD
  • JIT
  • tracepoint/syscalls/sys_enter_openat 这个字符串

再做两件事：

  1. 实验：把 ret0.bpf.c 里的节名改成 SEC("tracepoint/syscalls/no_such_event")，重新编译、重新生成骨架，观察这两步是否报错，并据此说明「节名的合法性由哪一步检查」；
  2. 选型：下面三个需求分别该用本页第 5 节的哪种工具，为什么？(a) 一次性查清哪个进程在反复打开 /etc/myapp/limits.conf；(b) 写一个带 -p PID 和 -d 秒数 参数、要分发给同事长期运行的打开文件监视工具；(c) 在一个已有的 Go 运维服务里加一段统计 TCP 重传次数的逻辑。

6.2 编程 ​

#46104
⚡3⏳2

写一个 insn_decode.c，把下面的字节数组按 8 字节一条拆成 eBPF 指令，打印每条指令的 opcode、dst、src、off、imm：

c
static const unsigned char bytes[] = {
    0xbf, 0x10, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
    0x04, 0x00, 0x00, 0x00, 0x03, 0x00, 0x00, 0x00,
    0x95, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
};

要求：

  1. 用一个位域结构体表示指令，字段按 code / dst / src / off / imm 排列；从 unsigned char 数组逐字节拼出字段，不要用结构体指针直接指向数组（说明这样做的理由）；
  2. 每条指令输出一行，格式如 0: code=0xbf dst=0 src=1 off=0 imm=0；
  3. 验收：把 int f(long x) { return x + 3; } 用 clang -target bpf -O2 -mcpu=v3 -c 编译，用 llvm-objdump -s -j .text f.o 取出 24 个字节，与上面数组对照；再用 llvm-objdump -d 看三行反汇编，确认解码出的 dst、src、imm 与助记符一致。然后再把同一个函数加上 -mcpu=v1 编译一次，说明为什么第二条指令的操作码从 0x04 变成了 0x07。
#46105
⚡3⏳3

写一个只支持 ldh、ldb、jeq、jgt、ret 的 cBPF 解释器，用它执行 47102 第 3 问写出的 IPv4 TCP 过滤器。

要求：

  1. 指令用 struct { uint16_t code; uint8_t jt; uint8_t jf; uint32_t k; } 表示，跳转按「下一条指令的编号加上 jt 或 jf」计算；
  2. 读包之前检查偏移加宽度是否越过帧长，越过时按丢弃处理并打印一行提示；
  3. 构造四个 64 字节的数组当作以太网帧：ARP（类型 0x0806）、IPv4 UDP（0x0800，协议号 17）、IPv4 TCP（0x0800，协议号 6）、IPv6（0x86dd），每行打印帧名和返回值；
  4. 验收：ARP、IPv4 UDP、IPv6 返回 0，IPv4 TCP 返回 0xffffffff。把 jeq 换成 jgt 再跑一遍，说明结果为什么变了。

参考实现放在 code/系统编程/拓展B_eBPF/B_1_eBPF概览/exercises/ 下，做完再对照。

#46106
⚡3⏳4

用普通 C 模拟 3.2 节讲的「事件驱动、附加在钩子上」的执行模型，写 hooksim.c：

  1. 定义三个事件 EVENT_OPENAT、EVENT_WRITE、EVENT_XDP，每个事件对应一张处理函数表，表项含事件、名字和函数指针；
  2. 每个处理函数接收一个 int 参数并打印自己的名字，用来观察谁被调用；
  3. trigger(event, arg) 只调用注册在该事件上的处理函数，同一事件上注册多个时全部按注册顺序调用；
  4. 为每个事件记一个触发计数，程序结束时打印三个事件的次数，没有注册处理函数的 EVENT_XDP 也要打印；
  5. 验收：依次触发 openat、write、xdp，输出中 openat 出现两行（两个处理函数各一行）、write 一行、xdp 零行，末尾打印 openat=1 write=1 xdp=1。

另外，用一张表把第 1 节的三条路与第 4 节的三个方向对上：每个方向举一个具体场景，写出它挂在哪个钩子（或哪种机制）上、为什么这个场景不该用内核模块。

最后回答两个问题：这段模拟在什么意义上对应 eBPF 的真实行为，在什么意义上不对应？如果 EVENT_XDP 上没有注册任何处理函数，真实内核里「附加了 XDP 程序但没有流量」与「根本没有附加程序」在可观测性上有什么区别？

#46107
⚡5⏳4

写一个 bpfobj.c，不包含 <elf.h>，自己定义 ELF64 文件头与节头的字段布局，读取一个 .bpf.o 并输出：

  1. e_machine 的值，并说明 247 对应哪一套指令集；
  2. 所有名字以 tp/、tracepoint/、kprobe/、xdp、cgroup/、lsm/、tcx/ 开头的节，打印节名与字节数；
  3. license 节的字节数与内容，.BTF 与 .BTF.ext 是否存在；
  4. 验收：对 ret0.bpf.o 的输出里有一行程序节、16 字节、machine 247；再写一个文件里放两个程序（tp/syscalls/sys_enter_write 与 tp/syscalls/sys_enter_read）的目标文件，输出两行、各 16 字节。

提示：节名字符串在 e_shstrndx 指向的那一节里，sh_name 是它的偏移；读文件里的任何结构都要先用 fseek 定位，不要假设节头在文件末尾。

参考实现放在 code/系统编程/拓展B_eBPF/B_1_eBPF概览/exercises/ 下。

6.3 综合与挑战 ​

#46108
⚡6⏳5

写一个 check.c，在「加载」之前对一个 eBPF 指令数组做静态检查，检查四项：

  1. 所有 opcode 都在支持的集合里（至少 0xb7、0xb4、0x07、0x0f、0x05、0x55、0x95）；
  2. 每条指令的 dst 和 src 都不大于 10；
  3. 无条件跳转与条件跳转的目标都落在 [0, n) 之内；
  4. 最后一条指令是 exit，且从第 0 条出发，所有可达路径最终都能到达某条 exit。

用四类输入测试并打印可读的报错：正常的两条指令、缺少 exit 的程序、跳转越界的程序、寄存器编号为 11 的程序。

做完之后读 B.9 里的验证器日志片段，用一段话说明你的检查器与它差在哪里，至少说出两项你完全没有检查的东西。

#46109
⚡7⏳5选做

把 46105 的 cBPF 解释器与一个最小 eBPF 解释器放进同一个程序，用同一套过滤逻辑做对照：

  1. eBPF 侧只实现 mov32/mov64 立即数、add 立即数、ldx、条件跳转、无条件跳转与 exit，寄存器用 int64_t r[11]；
  2. 为 ARP 过滤器手写等价的 eBPF 指令序列，语义与 cBPF 版本相同；
  3. 对 46105 的四类帧分别运行两个版本，打印两张结果表，断言两者一致；
  4. 统计两个版本在每类帧上各执行多少条指令，说明两者的差别来自哪里；
  5. 在报告里解释：两个版本的指令条数不同，为什么这不影响「两者语义相同」这个结论；再说明 eBPF 把 jt、jf 两个偏移换成一个偏移之后，同一条比较逻辑为什么常常要多出一条指令。

验收：四类帧的结果一致。做完之后把 eBPF 版本对应的目标文件用 llvm-objdump -d 反汇编一遍，说明反汇编器的助记符与你的写法差在哪里。

7. 参考资料 ​