5.12 eBPF 基础——现代 Linux 可观测性

预计阅读时间：14 分钟

学习目标

学完本章后，你将能够：

• 理解 eBPF 的核心架构（JIT 编译、Verifier 验证、BPF maps）
• 区分 kprobe、uprobe、tracepoint、USDT 四种探针类型与适用场景
• 使用 bcc 工具集（execsnoop、biolatency、tcplife）做日常排障
• 使用 bpftrace 编写一行流 eBPF 程序做深度诊断
• 了解 Cilium 和 Tetragon 在企业级网络与安全中的角色

核心知识

• eBPF（extended Berkeley Packet Filter）——在内核中运行沙箱化程序的框架，无需修改内核源码或加载内核模块
• JIT（Just-In-Time）编译器——将 eBPF 字节码转换为本地机器码，运行速度接近原生内核代码
• Verifier（验证器）——静态分析 eBPF 程序，拒绝无限循环、越界访问、未初始化变量等不安全行为
• BPF maps——eBPF 程序与用户空间共享数据的键值存储结构，支持数组、哈希表、LRU 等类型
• 探针类型——kprobe（内核函数入口/返回）、uprobe（用户态函数）、tracepoint（内核静态跟踪点）、USDT（应用预埋跟踪点）
• bcc（BPF Compiler Collection）——将 C 写的 eBPF 代码嵌入 Python/Lua 脚本的编译加载框架
• bpftrace——类似 awk 语法的高阶 eBPF 脚本语言，一行即可写出探针程序
• Cilium / Tetragon——基于 eBPF 的 K8s CNI 网络插件与运行时安全监控平台

知识关联

• 前置知识：2.4：进程管理 进程管理（理解进程与系统调用关系）、4.5：网络故障排查 网络故障排查（理解网络栈层次）
• 后续影响：eBPF 是容器网络（6.2：Kubernetes 入门 K8s 网络）、运行时安全、深度性能调优（4.6：Linux 性能调优）的基础技术
• 配套技术：系统调用跟踪（strace）、性能分析（perf）、容器网络（CNI）
• 内核版本要求：eBPF 基础功能需 Linux 4.1+；BPF maps 需 4.4+；CO-RE/BTF 需 5.4+；fentry/fexit 需 5.5+。生产环境建议内核 ≥ 5.4

原理讲解

eBPF 程序生命周期

一个 eBPF 程序从编写到加载挂载的流程如下：

1. 编写——用 C 语言编写 eBPF 内核态代码（限制：无循环、无 libc、有限栈大小）
2. 编译——由 LLVM/Clang 编译为 eBPF 字节码（ELF 目标文件）
3. 验证——加载时内核 Verifier 静态分析：控制流图确保有穷终止、模拟执行检查越界、类型检查参数
4. JIT 编译——通过通过验证后，内核 JIT 编译器将字节码转为当前 CPU 架构的本地机器码
5. 挂载——将 eBPF 程序附加到指定事件源（kprobe、tracepoint、XDP 等）
6. 交互——eBPF 程序通过 BPF maps 与用户空间通信（读/写/更新键值数据）
7. 卸载——程序不再使用时从内核卸载，释放资源

Verifier 的工作机制

Verifier 是 eBPF 安全性的核心保障。它以 DAG（有向无环图）方式遍历程序的每条执行路径，确保：

• 有穷终止——拒绝任何含有向后跳转的循环（除非有界循环被 LLVM 展开）
• 内存安全——每个内存访问都模拟检查指针范围和类型，禁止越界
• 栈深度限制——最大栈空间 512 字节，不允许递归调用
• 辅助函数白名单——eBPF 程序只能调用内核预定义的 bpf_* 辅助函数

探针类型对比

BPF maps 数据交互

BPF maps 是 eBPF 程序与用户空间之间的桥梁。内核态的 eBPF 程序写入 maps，用户态程序通过 bpf() 系统调用读取。常用 map 类型：

eBPF 程序类型与挂载点

除了探针（probe），eBPF 程序还能挂载到网络和追踪的关键位置。程序类型决定了它能调用哪些辅助函数、访问哪些上下文：

网络路径上 XDP 在收包最早期执行（驱动层、没有 skb 分配），性能比 TC 高一个数量级；XDP 放行/丢弃后包不进内核协议栈，常用于抗 DDoS 的丢包场景。Cilium 正是把 eBPF 挂在 TC 钩子上实现 Pod 网络策略，替代 iptables 链式遍历。

BTF 与 CO-RE

早期 eBPF 程序依赖内核头文件编译，换个内核版本就得重新编译（BPF 程序与内核强耦合）。BTF（BPF Type Format）把内核的类型信息以紧凑格式暴露给用户空间，CO-RE（Compile Once, Run Everywhere）让同一份编译产物在不同内核版本上直接加载——这是 eBPF 能被大规模分发到异构集群的前提。内核 5.4+ 默认开启 CONFIG_DEBUG_INFO_BTF，检查方法：

# 确认 BTF 支持
test -f /sys/kernel/btf/vmlinux && echo "BTF enabled" || echo "BTF missing"
# 输出: BTF enabled

# bpftool 查看 BTF 信息
bpftool btf dump file /sys/kernel/btf/vmlinux | head -5

# 为当前内核生成 vmlinux.h（写 CO-RE 程序时使用）
bpftool btf dump file /sys/kernel/btf/vmlinux format c > vmlinux.h

示例代码

1. 检查内核 eBPF 支持

# 查看内核是否开启了 eBPF 相关配置
cat /boot/config-$(uname -r) | grep BPF
# 输出:
# CONFIG_BPF=y
# CONFIG_BPF_SYSCALL=y
# CONFIG_BPF_JIT=y

# 查看已加载的 BPF 程序
bpftool prog list

# 查看 BPF 网络程序（XDP/TC）
bpftool net list

2. bcc 常用工具实战

# 安装 bcc 工具集
apt install -y bpfcc-tools
# 所有工具以 *-bpfcc 命名

# 追踪新进程创建（排查周期性高 CPU）
execsnoop-bpfcc
# 输出:
# PID   COMM             RET ARGS
# 1234  logrotate         0  /usr/sbin/logrotate /etc/logrotate.conf

# 追踪磁盘 I/O 延迟分布
biolatency-bpfcc
# 输出: 直方图显示 I/O 延迟分布区间

# 追踪 TCP 连接生命周期
tcplife-bpfcc
# 输出: 进程、源/目标 IP、端口、持续时间、收发字节数

# 追踪 OOM Killer
oomkill-bpfcc
# 输出: 谁触发了 OOM、kill 了哪个进程、分数多少

# 追踪慢文件 I/O（>10ms）
fileslower-bpfcc 10

3. bpftrace 一行流

# 安装 bpftrace
apt install -y bpftrace

# 统计每个进程的 read() 系统调用次数
bpftrace -e 'kprobe:sys_read { @[comm] = count(); }'

# 追踪 open 操作并打印文件名
bpftrace -e 'kprobe:do_sys_open { printf("%s: %s\n", comm, str(arg1)); }'

# 只追踪 >4KB 的大文件读取
bpftrace -e 'kprobe:vfs_read /arg2 > 4096/ { @[comm] = sum(arg2); }'

# 追踪新进程创建
bpftrace -e 'tracepoint:syscalls:sys_enter_execve { printf("%s -> %s\n", comm, str(args->filename)); }'

# 实时统计磁盘 I/O 按进程
bpftrace -e 'kprobe:submit_bio { @[comm] = count(); }'

# 查看可用探针列表
bpftrace -l 'tracepoint:syscalls:*'
bpftrace -l 'kprobe:tcp_*'

# 查看探针参数字段
bpftrace -lv 'tracepoint:syscalls:sys_enter_openat'
# 输出: filename, flags, mode

4. Cilium 与 Tetragon 部署

# Cilium — 基于 eBPF 的 Kubernetes CNI
# 替代 kube-proxy iptables，性能提升明显
helm repo add cilium https://helm.cilium.io/
helm install cilium cilium/cilium --namespace kube-system

# Tetragon — 基于 eBPF 的运行时安全监控
# 检测容器内新二进制执行、敏感文件读取、异常网络连接
# 无需修改应用代码即可获得安全可见性

5. bpftrace 生产排查示例集

# 场景一：CPU 突然飙高，找出谁在疯狂 fork 进程
bpftrace -e 'tracepoint:syscalls:sys_enter_fork { @[comm] = count(); }'
# 输出: @[java]: 12031, @[sh]: 342, ...

# 场景二：磁盘 IO 暴涨，定位读写进程与文件
bpftrace -e 'kprobe:blk_start_plug { @[comm] = count(); }'
bpftrace -e 'kprobe:vfs_read { @[comm, str(arg1)] = count(); }'

# 场景三：文件被谁删了（open 时打印调用栈）
bpftrace -e 'kprobe:do_unlinkat { printf("%s unlink %s\n", comm, str(arg1)); }'

# 场景四：网络重传排查（TCP 重传触发源）
bpftrace -e 'kprobe:tcp_retransmit_skb { @[comm, ntop(2, arg2)] = count(); }'

# 场景五：统计进程创建耗时分布（exec 延迟）
bpftrace -e 'kprobe:execve { @start[tid] = nsecs; } kretprobe:execve /@start[tid]/ { @ms = hist((nsecs - @start[tid]) / 1000000); delete(@start[tid]); }'

# 场景六：系统调用延迟直方图（按进程名分组）
bpftrace -e 'kprobe:do_sys_openat { @start[tid] = nsecs; } kretprobe:do_sys_openat { @ns[comm] = hist(nsecs - @start[tid]); delete(@start[tid]); }'

# 场景七：信号追踪（谁给谁发了什么信号）
bpftrace -e 'tracepoint:signal:signal_generate { printf("%s -> %s signal %d\n", comm, args->target, args->sig); }'

6. 用 Python + bcc 编写自定义工具

#!/usr/bin/env python3
# trace-opens.py —— 追踪指定进程的 openat 系统调用
from bcc import BPF

bpf_text = """
#include <uapi/linux/ptrace.h>
int trace_openat(struct pt_regs *ctx, const char __user *filename) {
    bpf_trace_printk("open: %s\\n", filename);
    return 0;
}
"""

bpf = BPF(text=bpf_text)
bpf.attach_kprobe(event="do_sys_openat", fn_name="trace_openat")
print("追踪 openat 调用，Ctrl+C 退出...")
bpf.trace_print()

# 运行：
# python3 trace-opens.py
# 输出: bash-1234 [000] .... 123.456789: open: /etc/passwd

#!/usr/bin/env python3
# vfs-latency.py —— 按进程统计 VFS 读写耗时
from bcc import BPF

bpf_text = """
#include <uapi/linux/ptrace.h>
BPF_HASH(start, u32);
BPF_HISTOGRAM(lat, u32);

int entry(struct pt_regs *ctx) {
    u32 pid = bpf_get_current_pid_tgid();
    start.update(&pid, &bpf_ktime_get_ns());
    return 0;
}

int exit(struct pt_regs *ctx) {
    u32 pid = bpf_get_current_pid_tgid();
    u64 *t = start.lookup(&pid);
    if (t) {
        u64 delta = bpf_ktime_get_ns() - *t;
        lat.increment(bpf_log2l(delta / 1000));
        start.delete(&pid);
    }
    return 0;
}
"""

bpf = BPF(text=bpf_text)
bpf.attach_kprobe(event="vfs_read", fn_name="entry")
bpf.attach_kretprobe(event="vfs_read", fn_name="exit")
bpf["lat"].print_log2_hist("VFS read latency (us)")

# 输出: 直方图显示各延迟区间的调用次数

常见错误

最佳实践

练习题

1. （概念）eBPF Verifier 主要检查程序的哪三类安全性问题？
2. （概念）tracepoint 和 kprobe 的区别是什么？生产环境为什么更推荐 tracepoint？
3. （实操）安装 bcc 工具集，使用 execsnoop-bpfcc 观察当你运行 ls 命令时触发的事件。
4. （实操）用 bpftrace 写一行命令，统计系统上所有进程调用 write 系统调用的次数（按进程名分组）。
5. （实操）使用 tcplife-bpfcc 观察当前系统的 TCP 连接，找到一条从本机到外部服务的连接记录并解释各字段。
6. （🔍 挑战）在一个 K8s 集群上部署 Cilium 替换 CNI，用 cilium connectivity test 验证网络连通性，对比替换前后 kubectl exec 跨节点通信延迟的变化。

学习检查点

学完本章后，请检验自己是否掌握以下内容：

本章总结

eBPF 是 Linux 内核近十年最重要的创新之一，它通过安全的内核沙箱化执行框架，重新定义了操作系统可观测性。核心流程为：C 编写 → LLVM 编译为字节码 → Verifier 安全验证 → JIT 编译为本地码 → 挂载到事件源 → 通过 BPF maps 与用户空间交互。

速查路线：

• 日常排错 → bcc 工具（execsnoop、biolatency、tcplife）
• 深度诊断 → bpftrace 一行流脚本
• 企业部署 → Cilium（网络）+ Tetragon（安全）

速查表

学习路径建议

• 学完本章后，建议继续学习 6.2：Kubernetes 入门 Kubernetes 网络原理理解 Cilium 的角色
• 进阶阅读：Cilium 官方文档
• 安全审计方向可读 5.13：auditd 审计 auditd 审计系统，对比 eBPF 方案的优劣

延伸阅读