eBPF 基础

loader 退出了，程序却还挂着；验证器通过了，计数仍可能丢失。eBPF 的对象寿命、内存安全证明和业务正确性是三件事。

本篇讨论扩展 BPF。seccomp 使用经典 BPF 过滤格式及专门系统调用语义，不能混作普通 eBPF 程序类型。

1. 生命周期里有多个独立对象

libbpf 协调 ELF 解析、重定位和内核接口调用；不能把加载成功当作已经挂接。

关闭 loader 进程不一定撤销所有程序：被 pin 或由其他对象引用的资源仍可能存在；不同 attach API 的寿命规则也不同。设计工具时应明确谁持有 link、是否 pin、退出时如何撤销，不能只依赖“进程结束应该会自动清理”。见 libbpf 总览。

2. Verifier 检查的是可证明的安全条件

验证器沿控制流传播抽象状态，跟踪寄存器与栈槽中的标量范围、指针类型、已初始化区域和需要释放的资源。它通过状态合并、剪枝等机制处理路径，不是把每种具体输入逐一执行一遍。

有界循环、bpf_loop 或迭代器等机制扩大了可表达范围，但并非任意循环都接受。程序指令数量与 verifier 探索复杂度是不同限制；不应把“一百万”同时当作源代码长度、运行次数和所有程序统一上限。

BPF 栈有严格限制，常见每个子程序栈帧上限为 512 字节；调用链、tail call 组合还会增加约束。tail call 的链式限制又不是普通 BPF-to-BPF 调用深度。应以目标内核的验证日志为准，而不是记住一张跨版本通用常数表。

非空证明与 key 范围不是一件事

下面是 map 查找后的局部模式，假设 counts 的 value 类型是 __u64，key 是已初始化的 __u32：

__u32 key = 7;
__u64 *value = bpf_map_lookup_elem(&counts, &key);
if (!value)
    return 0;
__sync_fetch_and_add(value, 1);

查找 helper 根据 map 类型和 key 内容决定结果；验证器要确认 key 内存可以读取，并在解引用 value 前确认它不是 NULL。不能把 if (x < 10) 当成任意 map 查找必定成功的证明，尤其 x 可能有符号而下界尚未检查。

普通 (*value)++ 对共享 value 的并发更新可能丢计数，例子使用原子加；原子操作仍要满足目标指令和访问约束。验证器接受不证明业务统计正确，也不保证内核或 verifier 的实现永无漏洞。见 verifier 文档。

把一次运行的 key 是否存在，与加载时的所有路径证明分开控制。即使这个样本恰好安全，未排除的 NULL 或越界路径仍会阻止加载。

3. JIT 降低解释开销，不消除所有成本

支持并启用 JIT 时，BPF 指令编译成目标机器码；其他可用执行路径取决于架构和构建配置。不能为所有 BPF 指令指定固定“对应 1 到 3 条 x86 指令”：调用、原子操作、检查和 JIT 加固都会影响生成代码。

运行成本还包括 hook、map 查找、锁、事件复制及用户态消费。验证发生在加载阶段，但源程序用于证明边界的判断可能仍保留在运行代码中，因此不能说“所有边界检查运行时零开销”。

4. Maps 是具有不同语义的状态对象

per-CPU 减少 CPU 间共享写入竞争，但不代表整个 map 实现“绝对无锁”，也不自动解决用户态读取时的一致性。hash 的结构更新与 value 内多个字段的原子一致性同样需要区分。

BPF 全局变量也能保留状态，libbpf 常把相关数据段组织为 map，因此“程序完全无状态”只是过度简化。更多语义见 BPF maps。

5. Ring buffer 与 perf buffer 如何选择

perf event array 常配合每 CPU perf 缓冲区输出 BPF 事件；BPF ringbuf 提供多生产者、单消费者的共享环形缓冲区，也可以用多个 ringbuf 分片。二者都支持变长记录，不能把 perf buffer 说成仅支持固定记录长度。

较早预留未完成，后面的事件也可能等待

ringbuf 的 reserve/submit 路径允许直接填充预留记录；较早预留的记录若尚未完成，会影响消费者继续读取后续记录。顺序对应同一个 ringbuf 内的预留序列，不等于跨 CPU 事件的绝对发生时间顺序，更不等于多个 ringbuf 之间有全局顺序。

两种方案都可能丢事件。ringbuf 预留失败要计数，perf buffer 的 lost 信息要处理；timestamp、CPU、事件标识和丢失计数应成为数据协议的一部分。是否共享内存、是否有复制也依具体输出 API 和消费路径不同，不能简单说 perf 固定两次复制、ringbuf 永远无复制。见 BPF ring buffer。

6. BTF 与 CO-RE 的兼容边界

BTF 描述类型等信息；CO-RE 在加载阶段利用目标 BTF 处理字段偏移、大小、存在性等重定位。BPF_CORE_READ(task, pid) 可以使字段移动后的访问仍正确，但不把整个内核内部 ABI 变成稳定接口。

程序最终还必须通过目标版本 verifier。

/sys/kernel/btf/vmlinux 常提供运行内核 BTF，模块 BTF 又有自己的可用条件。CO-RE 不必在每台目标机安装完整编译器，但构建与发布仍需规划最低能力、兼容路径及验证矩阵。

7. 权限和观察工具

加载 tracing 相关程序通常还涉及 CAP_PERFMON，网络管理类操作可涉及 CAP_NET_ADMIN；CAP_BPF 并不是所有 attach 的通行证。非特权 BPF 受 sysctl、程序类型及其他限制。LSM、lockdown 等还可能继续约束操作。

安装 bpftool 后，以下命令用于只读检查对象；能看到什么取决于权限：

bpftool prog show
bpftool map show
bpftool link show

bpftool feature probe 会通过尝试相关操作探测能力，不应把它当作纯粹读取一份静态版本表。JIT 指令展示也依权限和内核配置，不保证每个程序都有可导出的机器码。

继续阅读：程序类型、追踪与调试。