Linux eBPF 深度工程实战：从虚拟机内核到 XDP/LSM 全栈可编程架构

2 阅读 0 评论 0 点赞

Linux eBPF 深度工程实战：从虚拟机内核到 XDP/LSM 全栈可编程架构

自 Linux 3.18（2014 年）引入扩展型 BPF（eBPF）以来，它已从一个简单的数据包过滤器演进为一套完整的内核可编程框架。如今，eBPF 驱动着云原生网络（Cilium）、可观测性（Pixie）、安全策略（Falco/Tetragon）、性能分析（BCC/bpftrace）和负载均衡（Katran）等关键生产系统。本文将深入 eBPF 的完整技术栈：虚拟机指令集与验证器架构、BPF 类型格式（BTF）、多种映射数据结构、各类 attach 点与辅助函数、XDP/TC 网络数据通路、LSM 安全钩子、CO-RE 可移植方案，以及 libbpf 现代工具链。

一、eBPF 架构全景

1.1 设计哲学：让内核安全地运行用户代码

eBPF 的核心承诺是：用户态编写的程序可以在内核态执行，而不会导致内核崩溃、死循环或数据泄漏。这种安全保证通过三层机制实现：

验证器（Verifier）：静态分析 BPF 字节码的所有可能执行路径，拒绝不可达代码、越界访问和未初始化读取
JIT 编译：将验证通过的字节码翻译为原生机器码，接近手写内核模块的执行效率
沙箱执行：eBPF 程序在受限的 BPF 上下文中运行，不能任意访问内存，所有内核交互必须经过辅助函数（Helper Function）

1.2 程序类型与 attach 点

eBPF 的灵活性来自于其丰富的程序类型（bpf_prog_type），每种类型对应一类内核事件入口：

程序类型	attach 位置	典型用途
BPF_PROG_TYPE_KPROBE	任意内核函数的入口/返回点	性能剖析、系统调用跟踪
BPF_PROG_TYPE_TRACEPOINT	内核静态 tracepoint	低开销事件监测
BPF_PROG_TYPE_XDP	网卡驱动层的最早期 RX	DDoS 防护、负载均衡
BPF_PROG_TYPE_SCHED_CLS / TC	内核 traffic control 层	流量整形、协议解析
BPF_PROG_TYPE_SOCKET_FILTER	socket 收包路径	包捕获、协议过滤
BPF_PROG_TYPE_CGROUP_SKB	cgroup 的网络出入口	容器网络策略
BPF_PROG_TYPE_LSM	LSM 安全决策钩子	运行时安全强制执行
BPF_PROG_TYPE_STRUCT_OPS	替换内核函数指针	自定义 TCP Congestion Control
BPF_PROG_TYPE_TRACING	ftrace/uprobe/USDT	通用 tracing

1.3 执行流程总览

eBPF 程序的生命周期：用户态源码（C/Rust）→ clang 编译为 BPF 内核 ELF → 通过 bpf() syscall 加载 → 验证器检查 → JIT 编译 → 挂载到 hook 点 → 事件触发执行。

二、BPF 指令集与虚拟机架构

2.1 寄存器模型

eBPF 虚拟机使用 11 个 64 位寄存器和一个 512 字节的栈：

// BPF 寄存器约定
// r0  : 函数返回值 / 程序退出值
// r1-r5: 函数参数（caller-saved）
// r6-r9: 被调用者保存的寄存器
// r10 : 栈指针（只读，唯一指向当前栈帧）

struct bpf_insn {
    __s8    dst_reg : 4;   // 目标寄存器
    __s8    src_reg : 4;   // 源寄存器
    __s16   off;            // 有符号偏移
    __s32   imm;            // 有符号立即数
};

2.2 指令编码与验证

eBPF 指令长度为 8 字节，按 64 位对齐。验证器的核心任务是构建控制流图（CFG），检查每一条可达路径：

// 验证器的核心检查逻辑（简化）
1. 构建所有基本块 (Basic Block)
2. 模拟执行每条指令，记录寄存器状态
3. 检查：
   - 无向后跳转（防止死循环）
   - 栈访问不越界
   - 指针运算在合法范围内
   - 所有路径都有 exit 或 return
   - 无未初始化寄存器读取
   - 类型匹配正确

Linux 5.10+ 引入了 bounded loop 支持，但迭代次数必须有编译时可证明的上界，且不能超过 BPF_COMPLEXITY_LIMIT_JMP_SEQ（默认 8192 次）。

2.3 JIT 编译

验证通过后，JIT 编译器将 BPF 字节码翻译为 x86_64/ARM64 原生指令。在 x86_64 上，常见的映射包括：

BPF_REG_0~9 → RAX, RDI, RSI, RDX, R9, R8（其余溢出到栈）
BPF_REG_10 → RBP
辅助函数调用直接映射为内联 syscall 或内存访问
关闭 SMAP/STAC 保护以便访问 map 内存

三、BPF 类型格式（BTF）

3.1 BTF 的动机

在 BTF 出现之前，eBPF 程序对内核数据结构的访问完全依赖硬编码偏移量，这导致了严重的内核版本间兼容性问题。BTF（BPF Type Format）是一种与 CO-RE（Compile Once, Run Everywhere）紧密耦合的元数据格式，紧凑地编码了类型信息、函数签名和源码行号。

3.2 BTF 数据结构

// BTF 类型信息头
struct btf_type {
    __u32 name_off;     // 名称在字符串段中的偏移
    __u32 info;         // 类型种类 + vlen
    union {
        __u32 size;     // 结构体大小
        __u32 type;     // 引用类型 ID
    };
};

// 种类枚举（部分）
enum btf_kind {
    BTF_KIND_UNKN       = 0,   // 未知类型
    BTF_KIND_INT        = 1,   // 整数类型
    BTF_KIND_PTR        = 2,   // 指针
    BTF_KIND_ARRAY      = 3,   // 数组
    BTF_KIND_STRUCT     = 4,   // 结构体
    BTF_KIND_UNION      = 5,   // 联合体
    BTF_KIND_ENUM       = 6,   // 枚举
    BTF_KIND_FWD        = 7,   // 前向声明
    BTF_KIND_TYPEDEF    = 8,   // typedef
    BTF_KIND_VOLATILE   = 9,
    BTF_KIND_CONST      = 10,
    BTF_KIND_RESTRICT   = 11,
    BTF_KIND_FUNC       = 12,  // 函数
    BTF_KIND_FUNC_PROTO = 13,  // 函数原型
    BTF_KIND_VAR        = 14,  // 全局变量
    BTF_KIND_DATASEC    = 15,  // 数据段（用于 extern 变量重定位）
    BTF_KIND_FLOAT      = 16,
};

3.3 BTF 在 CO-RE 中的角色

CO-RE 的工作流程依赖于 BTF 重定位记录。当 eBPF 对象文件被加载时，libbpf 会：

读取目标内核的 BTF（/sys/kernel/btf/vmlinux）
解析 eBPF 对象中的 .BTF 和 .BTF.ext 段
对每个重定位记录，比较目标内核中对应字段的偏移/类型
必要时 patch 字节码中的立即数字段以适配目标内核

四、BPF 映射（Maps）— 用户/内核共享数据

4.1 映射类型全览

映射类型	特性	典型场景
BPF_MAP_TYPE_HASH	O(1) 查找，LRU 淘汰	会话状态、连接跟踪
BPF_MAP_TYPE_ARRAY	预分配固定大小，O(1)	直方图桶、配置表
BPF_MAP_TYPE_RINGBUF	MPSC，自动覆盖	事件流传输（首选）
BPF_MAP_TYPE_PERCPU_HASH/ARRAY	每 CPU 副本，零争用	高性能统计
BPF_MAP_TYPE_LPM_TRIE	最长前缀匹配	IP 路由/策略匹配
BPF_MAP_TYPE_LRU_HASH	LRU 淘汰的全局 hash	大规模缓存
BPF_MAP_TYPE_QUEUE/STACK	FIFO/LIFO	事件队列
BPF_MAP_TYPE_BLOOM_FILTER	概率型成员检测	快速预过滤
BPF_MAP_TYPE_CGROUP_STORAGE	per-cgroup 存储	容器级状态
BPF_MAP_TYPE_TASK_STORAGE	per-task 存储	进程级状态
BPF_MAP_TYPE_INODE_STORAGE	per-inode 存储	文件级状态

4.2 Ring Buffer 机制

BPF_MAP_TYPE_RINGBUF 是 Linux 5.8 引入的，是用户态和内核态间高效数据传输的关键设计：

// 内核侧
struct bpf_ringbuf {
    struct page *_pages;         // 2^N 页的连续内存
    unsigned int mask;           // 容量掩码
    atomic_t consumer_pos ____cacheline_aligned;  // 消费者读写位置（用户态）
    atomic_t producer_pos ____cacheline_aligned;  // 生产者读写位置（内核态）
    // 数据区域 = ring_area 起始偏移
    // 通知机制：kernel 写完数据后唤醒 poll
};

// 用户侧 API
struct ring_buffer *ringbuf = ring_buffer__new(map_fd, sample_cb, NULL, NULL);
ring_buffer__poll(ringbuf, 100);  // 阻塞等待事件
ring_buffer__consume(ringbuf);     // 非阻塞消费
ring_buffer__free(ringbuf);

Ring buffer 内部使用两个循环标记位区分"已消费"和"已写入"区域，支持零拷贝通知机制。当内核写入数据时，通过 epoll 为用户态提供可轮询的文件描述符。

4.3 映射的内存保证

所有映射页都是 mlock 的，不会被换出
percpu 变体完全消除 CPU 间的缓存行 bounce
用户态对 ring buffer 的读操作无需系统调用（memory-mapped）

五、辅助函数（Helper Functions）

辅助函数是 eBPF 程序与内核交互的唯一合法 ABI。每种程序类型有独立的允许辅助函数集合，由 bpf_func_proto 数组索引。

辅助函数	用途	上下文
bpf_map_lookup_elem / update_elem / delete_elem	映射读写	所有
bpf_probe_read_{kernel,user}	跨空间安全读取	kprobe/tracing
bpf_probe_write_{kernel,user}	跨空间写入（需 CAP_SYS_ADMIN）	kprobe/tracing
bpf_ktime_get_ns	高精度时钟	所有
bpf_get_current_pid_tgid / get_current_comm	获取当前进程信息	所有
bpf_perf_event_output	将数据写入 perf ring buffer	tracepoint/kprobe/tc/xdp
bpf_redirect / redirect_map	数据包重定向	XDP / TC
bpf_sk_lookup_*	socket 查找操作	cgroup/sock_addr
bpf_strncmp / bpf_get_stackid	字符串比较 / 获取调用栈	tracing

5.1 map 指针传递（BPF_MAP_TYPE_PERCPU_CGROUP_STORAGE 模式）

从 Linux 4.19 起，eBPF 可以直接将 map 指针传递给辅助函数（BPF_MAP_TYPE_ARRAY_OF_MAPS 和 BPF_MAP_TYPE_HASH_OF_MAPS），实现 map 内嵌套 map。这定义了一种间接的多级索引方案。

六、XDP — Express Data Path

6.1 架构原理

XDP（Express Data Path）在每个网卡的 NAPI poll budget 分配 sk_buff 之前，直接在 DMA 环形缓冲区上处理原始帧。这是内核中最早期的包处理点：

NIC RX → DMA → 驱动描述符环
  → XDP 程序在 alloc_skb 之前执行
    → XDP_PASS: 继续常规协议栈
    → XDP_DROP: 丢弃（最快）
    → XDP_TX: 从同一网卡发回
    → XDP_REDIRECT: 转发到另一网卡或 cpumap
    → XDP_ABORTED: 错误，触发跟踪

6.2 XDP 程序类型

XDP 原生模式：驱动实现 ndo_bpf 回调，性能最优（目前有约 20+ 驱动支持）
XDP 通用模式（SKB-based）：在 kernel 常规路径上模拟，兼容性最好
XDP 卸载：程序加载到网卡 SmartNet 硬件（Netronome/Mellanox/Broadcom）

6.3 XDP 转发实践

XDP 在 DDoS 缓解和 Layer-4 负载均衡中非常成功：

// 简化版 L4 XDP 负载均衡
SEC("xdp")
int xdp_loadbalancer(struct xdp_md *ctx) {
    void *data = (void *)(long)ctx->data;
    void *data_end = (void *)(long)ctx->data_end;
    
    struct ethhdr *eth = data;
    if ((void *)(eth + 1) > data_end)
        return XDP_DROP;
    
    struct iphdr *iph = data + sizeof(*eth);
    if ((void *)(iph + 1) > data_end)
        return XDP_DROP;
    
    // 1. 查找后端服务器
    __u32 dst_ip = iph->daddr;
    __u32 *backend_ip = bpf_map_lookup_elem(&backends_map, &dst_ip);
    if (!backend_ip)
        return XDP_PASS;
    
    // 2. 校验和重写（增量更新）
    __u32 old_daddr = iph->daddr;
    iph->daddr = *backend_ip;
    bpf_csum_diff(&old_daddr, 4, &iph->daddr, 4, 0);
   iph->check = fold_csum(iph->check + (old_daddr & 0xffff) + ((old_daddr >> 16) & 0xffff));
    
    // 3. 重定向到目标网卡的后端 CPU
    return bpf_redirect_map(&cpumap, target_cpu, XDP_DROP);
}

6.4 XDP 与 AF_XDP 协同

AF_XDP 提供从用户态直接到网卡的描述符通路。XDP 程序可以将包通过 bpf_redirect_map(&xsks_map, key, XDP_DROP) 重定向到 AF_XDP socket，实现高性能用户态网络栈（如 DPDK 替代方案）。

七、Traffic Control（TC）eBPF

与 XDP 不同，TC eBPF 在协议栈的套接口层操作，能访问完整的 sk_buff 和 bpf_skb_data 上下文：

clsact：在 ingress 路径上的无队列分类器，适合审计/修改包
sch_handle_egress：在出方向执行，适合 NAT/MTU 调整
连接端点：Cilium 用 TC 实现 kube-proxy 替换、带宽管理、socket-level 负载均衡

TC eBPF 能直接调用 bpf_skb_store_bytes 修改载荷，或者 bpf_skb_vlan_push/pop 操作 VLAN，相比之下 XDP 更早期但修改能力受限。

八、动态追踪：Kprobes、Tracepoints 和 Fentry

8.1 三种机制的权衡

机制	粒度	稳定性	性能
Kprobe/Kretprobe	任意内核指令	不稳定（函数可能变化/内联）	高（trap 开销）
Tracepoint	内核事件固定点	稳定	中（空转时也有 check 开销）
Fentry/Fexit (bpf_tracing)	函数入口/出口	需 BTF	最低（直接 trampoline）

Fentry/Fexit 是 Linux 5.5+ 基于 BTF 的新型 tracing 方案，通过轻量级 trampoline 直接调用 BPF 程序，性能接近原生函数调用，且能直接读取函数参数（无需 arg probe 编号猜测）。

8.2 Tracepoint 的静态事件挂载

内核 tracepoint 通过 TRACE_EVENT 宏定义，在 /sys/kernel/debug/tracing/events/ 下有对应目录。例如 syscalls:sys_enter_execve 的字段可以安全地从 BPF 程序中直接访问。

九、LSM BPF — 安全策略即代码

9.1 传统 LSM 的局限

传统 Linux Security Module（SELinux、AppArmor）需要重启才能重新配置策略，且策略语言不灵活，难以应对云原生环境的快速变化。

9.2 BPF LSM 的架构

// 挂载 LSM hook 的 eBPF 程序
SEC("lsm/file_open")
int BPF_PROG(file_open_audit, struct file *file, int ret)
{
    // ret 为非负值表示之前的 hook 已否决
    if (ret != 0)
        return ret;
    
    // 自定义逻辑：若路径匹配敏感模式，记录或拒接
    char comm[TASK_COMM_LEN];
    bpf_get_current_comm(&comm, sizeof(comm));
    
    struct inode *inode = file->f_inode;
    __u32 uid = bpf_get_current_uid_gid() & 0xFFFFFFFF;
    
    // 策略检查
    if (uid != 0 && is_sensitive_file(inode)) {
        bpf_printk("Unauthorized access by %s uid=%d\n", comm, uid);
        return -EPERM;
    }
    
    return 0;  // 允许
}

// 加载时为程序设置 attach type:
// prog_attach_type = BPF_LSM_MAC
// expected_attach_type = BPF_LSM_MAC

关键特性：BPF LSM 程序可以否决内核操作（返回非零 errno），这是其它大多数 BPF 程序类型无法做到的。在 Cilium Tetragon 中，BPF LSM 被用于：

文件访问控制（谁可以打开 /etc/shadow）
网络连接控制（限制进程的 connect 目标）
特权操作限制（限制 mount/ptrace 使用）
系统调用过滤（按进程画像限制可用 syscall）

十、CO-RE 与 libbpf 现代工具链

10.1 CO-RE 五步工作流

用 clang 编译时加上 -g 保留 BTF 信息
vmlinux.h 提供所有内核类型定义
头文件中使用 extern struct xxx {} __attribute__((preserve_access_index)) 声明
libbpf 在加载时读取 /sys/kernel/btf/vmlinux，重定位到目标内核偏移
用户态无需关心目标内核版本

// vmlinux.h 中声明
struct task_struct {
    // ...
} __attribute__((preserve_access_index));

// eBPF 程序
SEC("kprobe/do_sys_openat2")
int trace_open(struct pt_regs *ctx)
{
    struct task_struct *task = (struct task_struct *)bpf_get_current_task();
    // 在 CO-RE 模式下，直接访问 task->pid、task->comm 等
    // libbpf 自动 patch 到正确的偏移量
    pid_t pid = BPF_CORE_READ(task, pid);
    return 0;
}

10.2 libbpf 核心 API

API	作用
bpf_object__open()	解析 ELF 文件中的 BPF 程序和 map
bpf_object__load()	验证器检查 + JIT + bpf() 系统调用加载
bpf_program__attach()	自动选择最佳 attach 方式
bpf_map_update_elem()	用户态更新 map
bpf_map_lookup_elem() → NULL 检查	用户态读取 map 数据 (注意并发)
ring_buffer__new() / perf_buffer__new()	异步事件回调

10.3 libbpf 的 skeleton — 代码自动生成

bpftool gen skeleton 可以从 BPF 对象生成一个 C 头文件封装，使集成到用户态 C 项目像 include 头文件一样简单。

十一、eBPF 子系统同步机制

11.1 RCU 语义

地图元素上的 bpf_map_lookup_elem 返回的指针在 RCU read lock 下有效。内核程序需调用 bpf_rcu_read_lock() / bpf_rcu_read_unlock() (Linux 6.2+) 保护。

11.2 spinlock

BPF 地图的值可以加 spinlock（BPF_SPIN_LOCK）保护，避免每 CPU 计数器在多核上的竞态。仅限于 BPF 程序中使用（用户态不能获取 spinlock）。

11.3 原子操作

BPF_ATOMIC_ADD、BPF_ATOMIC_XCHG、BPF_ATOMIC_CMPXCHG 等 64/32 位原子操作可以安全地在 eBPF 中同步。

十二、eBPF 程序生命周期与资源管理

12.1 引用计数与 PIN

pinning ：通过 bpf_obj_pin(fd, path) 将 BPF 程序或 map 持久化到 /sys/fs/bpf/，防止在所有引用关闭时被释放

// 程序 pin 到 bpffs
int prog_fd = bpf_program__fd(prog);
bpf_obj_pin(prog_fd, "/sys/fs/bpf/xdp_firewall");

// 加载已 pin 的程序
int pinned_fd = bpf_obj_get("/sys/fs/bpf/xdp_firewall");

12.2 尾调用（Tail Calls）

程序 A 可以执行 bpf_tail_call() 跳转到另一个代表不同策略阶段的程序
替换当前执行上下文（不是函数调用），栈被重置
深度限制：33 级
通过 map of programs 传递目标程序和 key

// 主程序通过 map 执行尾调用
struct {
    __uint(type, BPF_MAP_TYPE_PROG_ARRAY);
    __uint(max_entries, 16);
    __type(key, __u32);
    __type(value, __u32);
} progs_map SEC(".maps");

SEC("xdp")
int xdp_entry(struct xdp_md *ctx)
{
    // 跳转到阶段 1
    bpf_tail_call(ctx, &progs_map, 0);
    return XDP_PASS;
}

SEC("xdp")
int xdp_stage1(struct xdp_md *ctx) {
    // 跳转到阶段 2
    bpf_tail_call(ctx, &progs_map, 1);
    return XDP_PASS;
}

十三、生产级部署模式

13.1 云原生网络：Cilium

Cilium 是 eBPF 在 Kubernetes 网络中的标杆实现，用 eBPF 替代 kube-proxy 的 iptables/IPVS，核心优势：

socket-level 负载均衡（bpf_sock）无需解封装
wireguard/IPsec 透明加密
ClusterMesh 跨集群通信
bandwidth manager 的 EDT (Earliest Departure Time) 限速
Hubble 基于 eBPF 的网络可观测性

13.2 可观测性：Pixie / Parca / Pyroscope

Pixie：使用 uprobe/USDT 自动捕获 HTTP/gRPC/MySQL/Postgres/Redis/Kafka 协议指标，零代码改动
Parca / Pyroscope：基于 perf_event 的连续 CPU profiling

13.3 安全：Falco 与 Tetragon

Falco： syscall 级别异常检测（kprobe + tracepoint + ring buffer），规则引擎匹配
Tetragon：基于 BPF LSM 的运行时安全执行，支持实时策略执行（不仅观察，还能阻断）

13.4 负载均衡：Katran (Meta)

Meta 公开的 Katran 是用 XDP 实现的 L4 负载均衡器，核心优势：

DSR（Direct Server Return）模式下仅需处理入方向流量
每个包仅解封装到第 4 层（IP+UDP）
单核 10Mpps+ 的转发性能（依赖网卡特性）

十四、开发调试最佳实践

14.1 验证器错误排查

当 bpf(BPF_PROG_LOAD) 失败时，检查：

log_level=2 开启验证器详细日志（bpf_attr.log_buf）
常见错误：无效的栈偏移访问、未初始化寄存器、不可达代码、指针运算出界、缺少 exit
bpftool prog load 可以直接测试加载并打印源码级提示

14.2 bpftool — 瑞士军刀

# 列出所有 BPF 程序
bpftool prog show

# 列出所有 BPF 映射
bpftool map show

# dump xlated 指令
bpftool prog dump xlated id 42

# dump jited 指令
bpftool prog dump jited id 42

# 列出内核 BTF
bpftool btf dump file /sys/kernel/btf/vmlinux format c > vmlinux.h

# 列出已挂载 tracepoint
bpftool perf show

14.3 BPF 自检测试 BPF_SYSCALL_TEST

通过 BPF_PROG_TEST_RUN 在不 attach 的情况下运行 eBPF 程序，输入输出可调节，适合 CI 中自动化测试。

十五、总结

eBPF 的出现彻底改变了内核扩展的方式：无需重新编译内核、无需编写内核模块、无需重启系统，就可以在生产环境中安全地运行自定义逻辑。从最早的包过滤到 XDP 高速路由、LSM 安全执行、cgroup 级 socket 操作、可定制调度器（BPF struct_ops），eBPF 正在逐步涵盖内核的每一个子系统。

当前 eBPF 生态每年都在快速演进：

可编程调度器：Linux 6.12+ 的 sched_ext 允许 eBPF 完全替换 CFS/EEVDF
TCP 拥塞控制 eBPF：允许程序参与 RTT 估算和窗口调整
GPU 集成：NVIDIA 正在探索 GPU 上执行 eBPF 进行性能分析
ARM64 扩展：PAC/BTI 安全特性与 BPF JIT 的兼容性

对于系统工程师来说，掌握 eBPF 不再是"可选的高级技能"，而是理解现代 Linux 基础设施运行方式的必要条件。

点赞(0) 打赏

本文分类：eBPF技术
本文标签：eBPF Linux内核 XDP LSM BTF CO-RE 网络安全可观测性
浏览次数：2 次浏览
发布日期：2026-10-09 22:03:46
本文链接：https://www.ybb.press/ebpf-tech/16357.html

上一篇 > Linux eBPF 深度实战：重定义内核可编程技术的未来
下一篇 > eBPF 网络流量观测深度实战：从 XDP 到 tc 的全栈可观测性工程

Linux eBPF 深度工程实战：从虚拟机内核到 XDP/LSM 全栈可编程架构

Linux eBPF 深度工程实战：从虚拟机内核到 XDP/LSM 全栈可编程架构

一、eBPF 架构全景

1.1 设计哲学：让内核安全地运行用户代码

1.2 程序类型与 attach 点

1.3 执行流程总览

二、BPF 指令集与虚拟机架构

2.1 寄存器模型

2.2 指令编码与验证

2.3 JIT 编译

三、BPF 类型格式（BTF）

3.1 BTF 的动机

3.2 BTF 数据结构

3.3 BTF 在 CO-RE 中的角色

四、BPF 映射（Maps）— 用户/内核共享数据

4.1 映射类型全览

4.2 Ring Buffer 机制

4.3 映射的内存保证

五、辅助函数（Helper Functions）

5.1 map 指针传递（BPF_MAP_TYPE_PERCPU_CGROUP_STORAGE 模式）

六、XDP — Express Data Path

6.1 架构原理

6.2 XDP 程序类型

6.3 XDP 转发实践

6.4 XDP 与 AF_XDP 协同

七、Traffic Control（TC）eBPF

八、动态追踪：Kprobes、Tracepoints 和 Fentry

8.1 三种机制的权衡

8.2 Tracepoint 的静态事件挂载

九、LSM BPF — 安全策略即代码

9.1 传统 LSM 的局限

9.2 BPF LSM 的架构

十、CO-RE 与 libbpf 现代工具链

10.1 CO-RE 五步工作流

10.2 libbpf 核心 API

10.3 libbpf 的 skeleton — 代码自动生成

十一、eBPF 子系统同步机制

11.1 RCU 语义

11.2 spinlock

11.3 原子操作

十二、eBPF 程序生命周期与资源管理

12.1 引用计数与 PIN

12.2 尾调用（Tail Calls）

十三、生产级部署模式

13.1 云原生网络：Cilium

13.2 可观测性：Pixie / Parca / Pyroscope

13.3 安全：Falco 与 Tetragon

13.4 负载均衡：Katran (Meta)

十四、开发调试最佳实践

14.1 验证器错误排查

14.2 bpftool — 瑞士军刀

14.3 BPF 自检测试 BPF_SYSCALL_TEST

十五、总结

Linux I/O 子系统与块层深度实战：从 VFS 到 io_uring 的全栈工程解析

Linux CPU 调度器深度实战：从 CFS 到实时调度的全栈工程解析

eBPF 网络流量观测深度实战：从 XDP 到 tc 的全栈可观测性工程

Linux 内核 RCU：Read-Copy-Update 并发机制深度工程实战

评论列表 共有 0 条评论

发表评论 取消回复

评论列表共有 0 条评论

发表评论取消回复