eBPF

一、eBPF：重塑 Linux 内核可观测性范式

eBPF（Extended Berkeley Packet Filter）是近年来 Linux 内核领域最具革命性的技术之一。它允许在不修改内核源码、不重新编译内核的前提下，在内核空间中安全地运行用户定义的程序。从 Linux 3.18 引入到如今的 5.x/6.x 内核，eBPF 已经从一个简单的数据包过滤器演变为一个强大的内核可编程框架。

eBPF 的核心价值在于：安全、高效、可编程。通过内核内的验证器（Verifier）确保程序不会崩溃内核，通过 JIT 编译实现接近原生的执行速度，同时又保持了极高的灵活性。如今，eBPF 广泛应用于网络（Cilium）、可观测性（Falco、Pixie）、安全（Tetragon）和性能分析（BCC）等领域。

二、eBPF 核心架构与执行流程

理解 eBPF 的工作原理需要先掌握其完整的执行流程：

1. 编写 eBPF 程序：通常使用 C 语言子集编写，受限于 eBPF 验证器的约束（无循环、有限栈空间、必须显式边界检查）
2. 编译为 BPF 字节码：通过 LLVM/Clang 前端编译为目标无关的 BPF 字节码（-target bpf）
3. 加载到内核：通过 bpf() 系统调用将字节码送入内核
4. Verifier 验证：内核验证器执行深度静态分析，确保程序无死循环、不访问非法内存、栈空间合法
5. JIT 编译：验证通过后，BPF 字节码被 JIT 编译为本机机器码执行
6. 事件触发执行：当挂载点的事件发生时（函数调用、网络包到达等），自动触发 eBPF 程序执行

三、eBPF Map：内核与用户空间的数据桥梁

Map 是 eBPF 程序与用户空间通信的核心数据结构，本质上是一种通用的键值存储。内核提供了多种 Map 类型：

• Hash Map：通用哈希表，适合计数、查找场景
• Array Map：索引数组，适合固定结构的状态存储
• Ring Buffer（BPF_MAP_TYPE_RINGBUF）：高性能环形缓冲区，替代 perf buffer 的新方案
• Perf Event Array：用于向用户空间发送事件数据
• LRU Hash/Per-CPU Hash：带 CPU 亲和性和 LRU 淘汰策略的变体

四、XDP：高性能网络数据包处理的杀手锏

eXpress Data Path（XDP）是 eBPF 在网络领域的杀手级应用。它在数据包刚进入网卡驱动层时就进行处理，早于内核协议栈，因此能实现极致的包处理性能。

4.1 XDP 工作原理

传统 Linux 数据包处理路径：网卡驱动 -> 分配 sk_buff -> 协议栈层层解析 -> 用户空间。这条路径涉及多次内存分配和上下文切换，开销巨大。

XDP 在网卡驱动中直接挂载 eBPF 程序，在 sk_buff 分配之前就对原始数据包进行处理。返回码决定数据包命运：

• XDP_PASS：交给内核协议栈继续处理
• XDP_DROP：直接丢弃
• XDP_TX：从同一网卡发回
• XDP_REDIRECT：转发到另一网卡或 CPU

4.2 XDP 实战：简单防火墙

以下示例展示了一个基于 XDP 的简单源 IP 封禁程序：

// xdp_firewall.c
#include <linux/bpf.h>
#include <linux/if_ether.h>
#include <linux/ip.h>
#include "bpf_helpers.h"

struct {
    __uint(type, BPF_MAP_TYPE_HASH);
    __uint(max_entries, 10000);
    __type(key, __u32);
    __type(value, __u64);
} blocked_ips SEC(".maps");

SEC("xdp")
int xdp_firewall_prog(struct xdp_md *ctx) {
    void *data_end = (void *)(long)ctx->data_end;
    void *data = (void *)(long)ctx->data;
    struct ethhdr *eth = data;
    struct iphdr *ip;

    // 边界检查
    if ((void *)(eth + 1) > data_end)
        return XDP_PASS;

    if (eth->h_proto != __constant_htons(ETH_P_IP))
        return XDP_PASS;

    ip = (void *)(eth + 1);
    if ((void *)(ip + 1) > data_end)
        return XDP_PASS;

    // 检查源 IP 是否在封禁列表
    __u64 *count = bpf_map_lookup_elem(&blocked_ips, &ip->saddr);
    if (count) {
        bpf_map_update_elem(&blocked_ips, &ip->saddr, (*count + 1), BPF_ANY);
        return XDP_DROP;  // 直接丢弃，性能极高
    }

    return XDP_PASS;
}

char _license[] SEC("license") = "GPL";

4.3 XDP 加载方式

• Native XDP：需要网卡驱动原生支持（i40、ixgbe、mlx5 等主流 10G+ 驱动已支持）
• Generic XDP：基于内核协议栈的通用实现，性能较低但兼容性好，适合测试
• Offloaded XDP：将 eBPF 程序卸载到网卡硬件执行（SmartNIC），性能最高

五、kprobe 与 uprobe：动态追踪的瑞士军刀

5.1 kprobe：内核函数的动态插桩

kprobe 允许在几乎任意内核函数的入口（或指定偏移）处插入探测点。当执行到该位置时，会触发注册的 eBPF 程序。典型应用场景：

• 追踪 do_sys_openat2 分析文件打开模式
• 监控 tcp_sendmsg/tcp_recvmsg 分析网络吞吐
• 观测 kmalloc/kfree 分析内存分配热点

5.2 uprobe：用户态函数的动态插桩

uprobe 与 kprobe 类似，但作用于用户态程序。可以指定二进制文件和函数符号，在执行到该函数时触发回调。实战场景：

• 追踪 libc 的 malloc/free 观察用户态内存分配
• 监控 Java 应用的 JIT 编译函数触发
• Nginx 请求处理入口耗时分析

5.3 实战：追踪 malloc 调用频率与延迟

#!/usr/bin/env bpftrace

// 追踪 libc malloc 并按时长统计
uprobe:/lib/x86_64-linux-gnu/libc.so.6:malloc
{
    @start[pid] = nsecs;
    @size[pid] = arg0;
}

uretprobe:/lib/x86_64-linux-gnu/libc.so.6:malloc
/@start[pid]/
{
    $duration_us = (nsecs - @start[pid]) / 1000;
    @lat_us = hist($duration_us);
    @total_calls++;
    delete(@start[pid]);
    delete(@size[pid]);
}

END {
    printf("Total malloc calls: %d\n", @total_calls);
    print(@lat_us);
}

六、工具链生态：BCC 与 bpftrace

直接编写 C 语言 eBPF 程序门槛较高，社区提供了两个高阶工具链降低使用复杂度：

6.1 BCC（BPF Compiler Collection）

BCC 提供 Python/Lua 前端，封装了 eBPF 程序的编译、加载、数据读取全流程。内置 100+ 开箱即用的性能分析工具：

• execsnoop：追踪新进程创建
• opensnoop：追踪文件打开操作
• biosnoop：追踪磁盘 I/O 请求
• tcpconnect/tcpaccept：追踪 TCP 连接
• funclatency：测量函数调用延迟

sudo funclatency -m 1 do_sys_openat2 即可显示 open() 系统调用的毫秒级延迟直方图。

6.2 bpftrace

bpftrace 是类 awk 的追踪语言，一条命令即可完成动态追踪。语法简洁但能力强大，适合即时诊断：

# 统计每个进程的系统调用速率
bpftrace -e "tracepoint:syscalls:sys_enter_* { @[comm] = count(); }"

# 追踪分配超过 1MB 的 malloc 调用
bpftrace -e "uprobe:libc:malloc /arg0 > 1048576/ { printf("%s malloc %d bytes\n", comm, arg0); }"

# 测量内核 TCP 重传事件
bpftrace -e "kprobe:tcp_retransmit_skb { @[comm] = count(); }"

七、libbpf CO-RE：一次编译到处运行

传统 eBPF 程序需要与目标机器的内核头文件匹配，跨机器运行极其不便。libbpf CO-RE（Compile Once, Run Everywhere）通过 BTF（BPF Type Format）和重定位记录实现了真正的可移植性。

CO-RE 的关键步骤：

1. 编译时使用 -g 生成 BTF 重定位信息
2. 运行时通过 vmlinux.h（包含所有内核类型定义）开发
3. libbpf 在加载时自动适配目标内核的结构体布局和字段偏移

这意味着同一份 eBPF 二进制可以在 4.15 到 6.x 的不同内核上直接运行，无需重新编译。

八、性能调优与最佳实践

8.1 减少 Map 操作开销

• 使用 BPF_MAP_TYPE_PERCPU_HASH 替代普通 Hash Map，避免 CPU 间的原子操作
• 聚合数据后再向用户空间推送，减少上下文切换次数
• 善用 Ring Buffer 替代 Perf Event Array，性能提升 3-5 倍

8.2 降低 verifier 拒绝风险

• 所有内存访问前必须做边界检查（if (ptr + size > data_end) return;）
• 使用 __builtin_preserve_access_index 保持 CO-RE 兼容性
• 循环展开替代显式循环，或使用 #pragma unroll
• 栈空间限制 512 字节，大数据结构使用 Map 传递

8.3 生产部署模式

• DaemonSet 部署：在 Kubernetes 中通过 DaemonSet 将 eBPF Agent 部署到每个节点
• Feature Detection：运行时检查内核版本和 BPF 特性可用性，做降级方案
• 资源隔离：为 eBPF 程序设置 CPU/Memory cgroup 限制，防止资源枯竭
• 安全沙箱：限制 eBPF 程序只能访问必要的内核接口和 Map

九、常见故障排查

9.1 Verifier 拒绝加载

• 检查 dmesg 中的 verifier 日志，详细到拒绝原因
• 增大 sysctl net.core.bpf_jit_kallsyms=1 获取更详细符号信息
• 使用 bpftool prog dump xlated 查看 JIT 编译后的指令

9.2 性能瓶颈定位

• Map 操作是主要开销，bpf_map_update_elem 涉及哈希计算
• 频繁的用户态-内核态切换会降低性能
• JIT 未启用时字节码解释执行，性能差数倍

9.3 事件丢失

• Ring Buffer 生产速度超过消费速度时事件会被覆盖
• 增大 ringbuf 的 max_entries 参数（必须是 2 的幂）
• 用户态使用 epoll 或 poll 及时消费数据

十、生产级场景推荐

根据实际项目经验，以下场景特别适合引入 eBPF 方案：

• 容器网络 CNI：替代 iptables/ipvs 实现高性能策略路由
• 全链路追踪：零侵入地收集应用层、系统层、网络层指标
• 安全审计：监控异常系统调用、网络外联、文件篡改行为
• 性能基线对比：灰度发布期间实时对比内核行为级差异
• 流量工程：DDoS 防护、Load Balancing 策略的动态调整

eBPF 正在重塑 Linux 内核的可观测性与可编程性边界。这项技术已成为云原生基础设施的核心组件，掌握它将使你在性能优化和安全防护领域占据先机。