eBPF 技术深度实战：重构 Linux 内核可观测性与网络的编程范式

6 阅读 0 评论 0 点赞

# eBPF 技术深度实战：重构 Linux 内核可观测性与网络的编程范式 eBPF（Extended Berkeley Packet Filter）是近年来 Linux 内核领域最具革命性的技术之一。它允许在不修改内核源码、不重新编译内核、不停机的情况下，在内核空间中安全地运行自定义程序。从 Cloudflare 的 DDoS 防护到 Meta 的负载均衡，从 Kubernetes 网络插件 Cilium 到可观测性工具 Falco，eBPF 正在重新定义 Linux 内核扩展的方式。 本文将深入剖析 eBPF 的完整技术栈：从指令集架构到 JIT 编译，从验证器到 Map 数据结构，从 XDP/TC 网络编程到 tracepoint/kprobe 追踪，再到可观测性工程实战，带你系统掌握这一现代 Linux 内核编程的核心技术。 ## 一、eBPF 核心架构 ### 1.1 从 BPF 到 eBPF 的演进 经典 BPF（cBPF）诞生于 1992 年，由 Steven McCanne 和 Van Jacobson 在劳伦斯伯克利实验室设计，最初用于网络包过滤（tcpdump 的前身）。它有 32 位字长、2 个寄存器（A 和 X），仅支持前向跳转，指令数上限 4096。 eBPF（Extended BPF）在 Linux 3.18（2014年）引入用户态 API，关键升级包括： - 11 个 64 位通用寄存器（R0-R10） - 函数调用指令（call） - 跳转偏移支持后向跳转（配合验证器约束） - BPF Type Format（BTF）类型元数据 - 丰富的 Map 数据结构 - JIT 编译器支持 8 种架构（x86_64、arm64、s390、ppc64、sparc64、mips、riscv、loongarch） - BPF-to-BPF 函数调用和尾调用 ### 1.2 eBPF 程序生命周期 ``` 用户空间内核空间 ───────── ───────── 1. 编写 eBPF 代码（C/Rust） 2. 编译为 BPF ELF 对象文件（target=bpf） clang -target bpf -O2 -g -c prog.c -o prog.o 3. 调用 BPF(BPF_PROG_LOAD) ──────────────→ 4. 验证器（Verifier）执行静态分析 - 模拟执行所有路径 - 检查内存访问边界 - 检查指针运算合法性 - 检查终止性（无无限循环） 5. 验证通过 → JIT 编译为原生机器码 验证失败 → 返回详细错误日志 ←──── 6. 返回 prog_fd（文件描述符） 7. 通过 setsockopt/TC/XDP attach 到 hook 点 8. 程序在 hook 点被触发执行 ``` ### 1.3 BPF 寄存器与调用约定 ``` R0 - 返回值（函数返回 / 程序退出值） R1-R5 - 函数参数（caller → callee），也是程序输入参数 ctx 的位置 R6-R9 - 被调用者保存寄存器（callee-saved） R10 - 栈指针（只读，唯一允许直接读取的栈寄存器） 程序入口：R1 指向 __sk_buff（XDP/TC）或 pt_regs（kprobe）等上下文结构 程序退出：R0 存放返回码（XDP_ACT_DROP/PASS/TX 等） ``` ## 二、eBPF 指令集与编程模型 ### 2.1 BPF 指令编码 每条 BPF 指令为 64 位固定长度： ``` 0 1 2 3 4 5 6 0123456789012345678901234567890123456789012345678901234567890123 ├─────────┼────┼────┼─────────────┼─────────────┼─────────────────┤ │ opcode │ dst│ src│ offset │ imm │ (32 bits) │ │ 8 bit │ 4b │ 4b │ 16 bit │ 32 bit │ │ └─────────┴────┴────┴─────────────┴─────────────┴─────────────────┘ opcode 编码： - 指令类（低3位）：BPF_LD/LDX/ST/STX/ALU64/JMP/JMP32 - 模式（3-5位）：BPF_IMM/ABS/IND/MEM/SX/ATOMIC - 宽度（6-7位）：W(32)/H(16)/B(8)/DW(64) - 源（8位）：BPF_K(常量)/BPF_X(寄存器) ``` ### 2.2 内存访问指令 ```c // BPF_LDX_MEM(BPF_W, R2, R1, offsetof(struct ethhdr, h_proto)) // 对应 C：R2 = *(u32 *)((char *)R1 + offset) // BPF_STX_MEM(BPF_W, R10, R2, -4) // 对应 C：*(u32 *)(R10 - 4) = R2 （栈上临时存储） // BPF_ST_MEM(BPF_W, R10, -8, 0) // 对应 C：*(u32 *)(R10 - 8) = 0 （栈上初始化） ``` ### 2.3 ALU64 关键指令 ```c // 算术运算 BPF_ADD dst, src // dst += src BPF_SUB dst, src // dst -= src BPF_MUL dst, src // dst *= src （3.18+, 验证器跟踪边界） BPF_DIV dst, src // dst /= src （需验证 src != 0） BPF_MOD dst, src // dst %= src // 位运算 BPF_AND/OR/XOR/LSH/RSH/ARSH // 条件跳转（关键安全约束：必须有确定边界） BPF_JMP+BPF_JEQ k, label // if (dst == k) goto label BPF_JMP+BPF_JGT k, label // if (dst > k) goto label （仅限有符号/无符号明确场景） BPF_JMP+BPF_JGE X, label // 支持寄存器比较的跳转 ``` ## 三、验证器（Verifier）深度剖析 验证器是 eBPF 安全模型的核心，它对每个程序执行完整的静态分析确保安全性。 ### 3.1 验证流程 ``` 1. CFG 构建：将字节码转换为有向基本块图 2. Liveness 分析：确定每个程序点活跃的状态： - 寄存器值类型（SCALAR/PTR_TO_STACK/PTR_TO_MAP/...） - 寄存器边界（umin/umax/smin/smax） - 对齐状态 3. 路径模拟：DFS 遍历所有可达路径 4. 基本块验证：每条指令在目标状态下执行前检查： - 操作数类型合法（不能对 SCALAR 解引用） - 边界匹配（packet 访问不越界） - 终止性保证（循环展开验证） ``` ### 3.2 寄存器状态类型 ``` SCALAR_VALUE - 未知标量值（不能解引用） PTR_TO_STACK - 指向 BPF 栈的指针（spill/fill） PTR_TO_MAP_VALUE - 指向 map value 的指针 PTR_TO_MAP_KEY - 指向 map key 的指针 PTR_TO_CTX - 指向程序上下文（xdp_md/__sk_buff） PTR_TO_PACKET - 指向数据包起始（ pkt_start/pkt_end 边界） PTR_TO_MEM - 指向通用内存（map value/栈） PTR_TO_TP_BUFFER - 指向 tracepoint 的 per-CPU buffer ``` ### 3.3 边界跟踪示例 ```c // 验证器对这段跟踪代码的边界分析： struct xdp_md *ctx = (struct xdp_md *)PT_REG_CTX(ctx); void *data_end = (void *)(long)ctx->data_end; void *data = (void *)(long)ctx->data; if (data + sizeof(struct ethhdr) > data_end) return XDP_DROP; // 验证器跟踪到：此分支中 data+14 <= data_end struct ethhdr *eth = data; // 验证器记录：{type=PTR_TO_PACKET, offset=0, size=14} if (eth->h_proto == htons(ETH_P_IP)) { struct iphdr *ip = data + sizeof(struct ethhdr); // 验证器要求必须先检查 ip 边界 if ((void *)(ip + 1) > data_end) return XDP_DROP; // 跟踪 ip->ihl 取值范围 [5, 15]（首部长度字段的 4 位值） __u8 ihl = ip->ihl; // 验证器能推算出 ihl*4 的范围 [20, 60] } ``` ## 四、Map 数据结构 Map 是 eBPF 内核态与用户态通信的主要通道，也是多个 eBPF 程序间共享数据的机制。 ### 4.1 Map 类型体系 ``` 通用 Map： BPF_MAP_TYPE_HASH - 哈希表，O(1) 查找，支持 per-CPU 变体 BPF_MAP_TYPE_ARRAY - 数组索引，固定大小，最高效 BPF_MAP_TYPE_PERCPU_HASH - 每 CPU 独立哈希表，避免原子操作 BPF_MAP_TYPE_LRU_HASH - LRU 淘汰策略的哈希表 BPF_MAP_TYPE_LPM_TRIE - 最长前缀匹配树（路由查找） 专用 Map： BPF_MAP_TYPE_PROG_ARRAY - 存储 prog_fd，用于尾调用路由 BPF_MAP_TYPE_PERF_EVENT_ARRAY - perf 事件环形缓冲区（用户态通信） BPF_MAP_TYPE_STACK_TRACE - 内核调用栈 ID → 符号映射 BPF_MAP_TYPE_RINGBUF - 5.8+ 新一代环形缓冲区（替代 perf） BPF_MAP_TYPE_CPUMAP - CPU 重定向映射（XDP 专用） BPF_MAP_TYPE_XSKMAP - XDP socket 重定向映射 BPF_MAP_TYPE_DEVMAP - 网络接口重定向映射 BPF_MAP_TYPE_SOCKMAP - Socket 重定向映射（sockmap/sockhash） BPF_MAP_TYPE_QUEUEMAP - 包排队映射 ``` ### 4.2 BPF_MAP_TYPE_RINGBUF 深入分析 RINGBUF 是 Linux 5.8 引入的新一代 IPC 机制，解决 perf buffer 的数据丢失和内存浪费问题： ```c // 内核侧 struct { __uint(type, BPF_MAP_TYPE_RINGBUF); __uint(max_entries, 1 << 24); // 256MB } ringbuf SEC(".maps"); // 用户态通过 libbpf ring_buffer API struct ring_buffer *rb = ring_buffer__new(bpf_map__fd(obj->maps.ringbuf), on_event, NULL, NULL); // on_event 回调 static int on_event(void *ctx, void *data, size_t size) { struct event *e = data; printf("PID=%d COMM=%s SYSCALL=%d\n", e->pid, e->comm, e->syscall_id); return 0; } // 内核侧投放事件 struct event *e = bpf_ringbuf_reserve(&ringbuf, sizeof(*e), 0); if (!e) return 0; e->pid = bpf_get_current_pid_tgid() >> 32; bpf_get_current_comm(e->comm, sizeof(e->comm)); e->syscall_id = ctx->__syscall_nr; bpf_ringbuf_submit(e, 0); ``` ### 4.3 Map 生命周期与 BPF 特权 ``` BPF_MAP_CREATE → 需要 CAP_BPF 或 CAP_SYS_ADMIN MAP 访问 → 通过 fd，支持命名空间隔离（freeze/cgroup 委托） BPF token → Linux 6.9+ 引入，允许非特权创建 map 和 program ``` ## 五、XDP 编程实战 XDP（eXpress Data Path）是最快的网络数据包处理路径，在内核分配 sk_buff 之前执行。 ### 5.1 XDP 执行流水线 ``` 网卡驱动 → XDP 程序（Native/Offload） ↓ 返回码： XDP_DROP - 立即丢弃（DDOS 场景） XDP_PASS - 继续进入内核网络栈 XDP_TX - 从原接口发回（反射/负载均衡） XDP_REDIRECT - 转发到另一个接口/CPU/XSOCKET XDP_ABORTED - 异常（触发 tracepoint） ``` ### 5.2 XDP L4 负载均衡器实现 ```c #include <linux/bpf.h> #include <linux/if_ether.h> #include <linux/ip.h> #include <linux/tcp.h> #include <linux/in.h> #include <bpf/bpf_helpers.h> #include <bpf/bpf_endian.h> struct backend { __u32 ip; unsigned char mac[ETH_ALEN]; __u64 pad; }; // 后端服务器列表 struct { __uint(type, BPF_MAP_TYPE_ARRAY); __type(key, __u32); __type(value, struct backend); __uint(max_entries, 256); } backends SEC(".maps"); // 会话亲和表：客户端IP → 后端索引 struct { __uint(type, BPF_MAP_TYPE_LRU_HASH); __type(key, __u32); __type(value, __u32); __uint(max_entries, 100000); } session_affinity SEC(".maps"); // 统计计数 struct { __uint(type, BPF_MAP_TYPE_PERCPU_ARRAY); __type(key, __u32); __type(value, __u64); __uint(max_entries, 8); } stats SEC(".maps"); SEC("xdp") int xdp_lb(struct xdp_md *ctx) { void *data_end = (void *)(long)ctx->data_end; void *data = (void *)(long)ctx->data; struct ethhdr *eth = data; if ((void *)(eth + 1) > data_end) return XDP_DROP; __builtin_memcpy(eth->h_dest, , ETH_ALEN); // placeholder for dest mac if (eth->h_proto != bpf_htons(ETH_P_IP)) return XDP_PASS; struct iphdr *ip = data + sizeof(struct ethhdr); if ((void *)(ip + 1) > data_end) return XDP_DROP; if (ip->protocol != IPPROTO_TCP) return XDP_PASS; struct tcphdr *tcp = (void *)ip + ip->ihl * 4; if ((void *)(tcp + 1) > data_end) return XDP_DROP; // 仅处理目标端口 80 if (bpf_ntohs(tcp->dest) != 80) return XDP_PASS; __u32 client_ip = bpf_ntohl(ip->saddr); __u32 *backend_idx = bpf_map_lookup_elem(&session_affinity, &client_ip); __u32 idx; if (backend_idx) { idx = *backend_idx; } else { // 简单轮询（实际生产用一致性哈希） __u32 counter_key = 0; __u64 *counter = bpf_map_lookup_elem(&stats, &counter_key); if (!counter) return XDP_DROP; idx = __sync_fetch_and_add(counter, 1) % 3; // 3个后端 } struct backend *be = bpf_map_lookup_elem(&backends, &idx); if (!be) return XDP_DROP; // 重写MAC地址 __builtin_memcpy(eth->h_dest, be->mac, ETH_ALEN); ip->daddr = bpf_htonl(be->ip); // 更新会话亲和 if (!backend_idx) bpf_map_update_elem(&session_affinity, &client_ip, &idx, BPF_ANY); return XDP_TX; // 直接转发出去 } char _license[] SEC("license") = "GPL"; ``` ### 5.3 编译与加载 ```bash # 编译 clang -O2 -g -target bpf -c xdp_lb.c -o xdp_lb.o # 加载到网卡 ip link set dev eth0 xdp obj xdp_lb.o sec xdp # 查看已加载的 eBPF 程序 bpftool prog show bpftool net show # 查看 map bpftool map show bpftool map dump id <map_id> # 卸载 ip link set dev eth0 xdp off ``` ## 六、Tracepoint 与 Kprobe 可观测性 ### 6.1 Tracepoint 类型选择 ```c // Tracepoint：内核静态钩子，ABI 稳定，推荐首选 SEC("tp/syscalls/sys_enter_execve") int trace_execve(struct trace_event_raw_sys_enter *ctx) { struct event e = {}; bpf_probe_read_user_str(e.filename, sizeof(e.filename), (char *)ctx->args[0]); e.pid = bpf_get_current_pid_tgid() >> 32; e.ts = bpf_ktime_get_ns(); bpf_perf_event_output(ctx, &events, BPF_F_CURRENT_CPU, &e, sizeof(e)); return 0; } // Kprobe：动态插桩任意内核函数 SEC("kprobe/tcp_sendmsg") int trace_tcp_sendmsg(struct pt_regs *ctx) { struct sock *sk = (struct sock *)PT_REGS_PARM1(ctx); u16 family = 0; bpf_probe_read_kernel(&family, sizeof(family), &sk->sk_family); if (family != AF_INET) return 0; // ... return 0; } // Fentry/Fexit：5.5+ 高性能函数入口/出口追踪 SEC("fentry/tcp_sendmsg") int BPF_PROG(trace_tcp_sendmsg, struct sock *sk, struct msghdr *msg, size_t size) { // 直接访问参数，比 kprobe 快 3-5 倍 // 支持 bpf_modify_return 修改返回值 return 0; } // Tracepoint 与 Kprobe 对比 // 名称性能 ABI稳定性覆盖度返回值修改 // Tracepoint ★★★ 稳定仅静态点 ✗ // Kprobe ★★ 不稳定任意内核函数 ✓(kretprobe) // Fentry ★★★★★ 较稳定静态编译函数 ✓(fexit) ``` ### 6.2 可观测性实战：跟踪 openat 系统调用 ```c // opensnoop.bpf.c struct { __uint(type, BPF_MAP_TYPE_HASH); __type(key, u32); // pid __type(value, struct args_t); __uint(max_entries, 10240); } start SEC(".maps"); struct { __uint(type, BPF_MAP_TYPE_PERF_EVENT_ARRAY); __type(key, u32); __type(value, u32); } events SEC(".maps"); struct event { u32 pid; u32 uid; int ret; char comm[16]; char fname[256]; }; SEC("tp/syscalls/sys_enter_openat") int trace_enter(struct trace_event_raw_sys_enter *ctx) { u64 pid_tgid = bpf_get_current_pid_tgid(); struct args_t args = {}; args.fname_ptr = (char *)ctx->args[1]; args.flags = (int)ctx->args[2]; bpf_map_update_elem(&start, &pid_tgid, &args, BPF_ANY); return 0; } SEC("tp/syscalls/sys_exit_openat") int trace_exit(struct trace_event_raw_sys_exit *ctx) { u64 pid_tgid = bpf_get_current_pid_tgid(); struct args_t *argsp = bpf_map_lookup_elem(&start, &pid_tgid); if (!argsp) return 0; struct event e = {}; e.pid = pid_tgid >> 32; e.uid = bpf_get_current_uid_gid(); e.ret = ctx->ret; bpf_get_current_comm(e.comm, sizeof(e.comm)); bpf_probe_read_user_str(e.fname, sizeof(e.fname), argsp->fname_ptr); bpf_perf_event_output(ctx, &events, BPF_F_CURRENT_CPU, &e, sizeof(e)); bpf_map_delete_elem(&start, &pid_tgid); return 0; } ``` ## 七、BPF Type Format（BTF） BTF 是 eBPF 生态的"元数据层"，使 eBPF 程序具备跨内核版本的 CO-RE（Compile Once - Run Everywhere）能力。 ### 7.1 BTF 核心能力 ``` 类型信息 → bpf_core_field_exists() / bpf_core_read() 重定位 → bpf_core_field_offset() → 自动适配不同内核版本的字段偏移 重命名 → 内核结构体字段重命名后的自动适配 .enum值 → 内核枚举值变更后的自动适配 ``` ### 7.2 CO-RE 迁移示例 ```c // 非 CO-RO：硬编码偏移（内核升级即崩溃） u64 addr = *(u64 *)((char *)task + 0x450); // CO-RE 自适应： #include "vmlinux.h" // 从目标系统提取的完整类型定义 #include <bpf/bpf_core_read.h> // CO-RE 重定位宏 struct task_struct *task = (struct task_struct *)bpf_get_current_task(); u64 start_time = BPF_CORE_READ(task, start_time); // 编译器记录重定位信息，libbpf 加载时根据目标内核 BTF 自动修正 // 处理内核结构体字段重命名（如 task_struct->state → __state） u64 state = BPF_CORE_READ(task, __state); // 重定位自动适配 ``` ### 7.3 生成目标系统 BTF ```bash # 方法1：从目标系统提取 bpftool btf dump file /sys/kernel/btf/vmlinux format c > vmlinux.h # 方法2：使用 libbpf 内置 vmlinux.h（常用发行版预生成） # libbpf/src/bpf梓-vmlinux.h（常见内核版本） # 方法3：小尺寸 BTF（用于嵌入式） pahole --btf_gen_all -j vmlinux # 验证 BTF 可用性 bpftool btf dump file program.o ``` ## 八、eBPF 安全防护与故障排查 ### 8.1 常见验证器拒绝场景 ``` 错误类型解决方案 ───────────────────────────────────────────────── min value must be >= 0 添加边界检查 R1 invalid mem access 'inv' 先做 NULL 检查 R1 !read_ok 对指针使用 bpf_probe_read_kernel packet pointer range check 校验后加 data + offset < data_end back-edge from insn 45 to 8 循环需使用 #pragma unroll 或 BPF bounded loop ``` ### 8.2 verifier 日志解读 ```bash # 获取详细验证日志 ./bpftool prog loadall xdp_prog.o /sys/fs/bpf/xdp_prog 2>&1 | head -100 # 日志示例： # 45: (61) r1 = *(u64 *)(r10 - 48) # R1=fp-48 # process_xdp:45(packet_size=2048) # 46: (bf) r2 = r1 # r2 = r1 = fp-48 # 47: (07) r2 += 14 # r2 = fp-34 # finalizer_process_xdp: # off=0 size=8 imm=0 # 验证失败：边界跟踪错误 ``` ### 8.3 性能调优 ``` bpf_jit_kallsyms=1 # 将 JIT 代码导出到 /proc/kallsyms bpf_jit_harden=1 # JIT 安全加固（常量盲化） bpf_jit_limit=264241152 # JIT 内存限制（字节） ``` ## 九、生产环境实战经验 ### 9.1 eBPF 可观测性架构设计 ``` 用户态 Collectors ┌─────────────────────┐ eBPF Programs │ Prometheus/ │ ─────────── │ Grafana/ │ ┌──────────┐ │ OpenTelemetry/ │ │ XDP │──Ring──│ Vector/Fluent Bit │ │ TC │──buf──▶│ ↓ │ │ Kprobe │ │ ClickHouse/ │ ──▶ Dashboard │ Tracepoint│──perf─│ InfluxDB/ │ Alerting │ Fentry │ event │ Loki/Elastic │ SSI │ LSM │ │ │ │ Cgroup │──Map──▶│ Control Plane │──▶ Controller └──────────┘ └─────────────────────┘ ``` ### 9.2 大规模部署注意事项 1. **内存限制**：cgroup BPF 模式下，每个 cgroup 的 eBPF RIB 有限；使用 BPF token 委托避免 mount操作频繁切换 2. **尾调用链深度**：最大 32 级（ BPF_MAIN_FUNC → 尾调用32次），超过则验证失败 3. **指令数限制**：Linux 5.2+ 100 万条指令；旧版 4096 条 4. **栈空间**：每程序严格 512 字节，大数据需用 map 或 per-CPU array 5. **CPU 亲和**：使用 BPF_MAP_TYPE_PERCPU_* 避免跨 CPU 原子操作 6. **map-in-map**：复杂路由场景使用 prog_array/map_of_maps 减少全局锁 ### 9.3 工具链推荐 ``` 用途工具 ──────────────────────────────────────────────────── 开发编译 clang/llvmlang, libbpf (bpf__open/对象文件加载) 单步调试 bpftool prog run (Linux 5.16+) 性能分析 bpftool prog profile 动态加载/卸载 bpftool prog load Python 开发 bcc (BCC) Go 开发 cilium/ebpf, libbpfgo Rust开发 libbpf-rs, aya(Rust原生框架) 可视化排错 bpftool prog xlated dump (查看 JIT/解释代码) 可观测性生产部署 Hubble(Cilium), Pixie, Parca(eBPF Profiling) ``` ## 十、未来演进 ### Linux 内核路线图 ``` Linux 5.17+ - BPF trampoline 用于 fentry/fexit/kprobe Linux 5.18+ - riscv JIT 编译器 Linux 6.0+ - BPF token 概念引入 Linux 6.1+ - BPF trampoline 支持 kprobe 多链接 Linux 6.6+ - BPF Arena（共享内存新机制） Linux 6.7+ - 设备专有 BPF program type Linux 6.8+ - bpf_timer 改进 Linux 6.9+ - BPF token 完整实现（非特权 eBPF） Linux 7.0(预计) - BPF 性能剖析增强 ``` ### 关键技术趋势 1. **非特权 eBPF（BPF token）**：Linux 6.9+ 通过 token 委托机制让非 root 进程在 cgroup 内安全使用 eBPF 2. **BPF Arena**：共享内存区域，支持用户态和 eBPF 程序原子操作 3. **硬件 offload**：NVIDIA ConnectX 网卡支持 XDP 硬件卸载 4. **安全扩展**：LSM BPF 成为容器安全标准运行时（Falco/Tracee/Tetragon） 5. **调度器 BPF**：探索 BPF 程序在 CPU/IO 调度决策中的应用 ## 总结 eBPF 已经从早期的包过滤演进为覆盖网络、安全、可观测性、性能剖析的通用内核编程平台。其核心价值在于：在不牺牲稳定性和安全性的前提下，实现生产环境的动态内核扩展能力。掌握 eBPF 技术栈——从汇编指令到验证器原理，从 Map 设计到 JIT 编译，从网络接口到 CO-RE 迁移——是构建现代化 Linux 基础设施的必备技能。随着 Linux 6.x 内核 BPF token 机制的落地，非特权容器中的 eBPF 应用将进一步加速云原生生态的演进。 --- **延伸阅读**：深入了解 BPF Type Format 内部编码结构、BTF deduplication 算法、eBPF 在 K8s 网络策略（Cilium Network Policy）中的应用，以及基于 eBPF LSM 的零信任安全模型。

点赞(0) 打赏

本文分类：eBPF技术
本文标签：eBPF Linux内核 XDP BPF JIT 内核编程可观测性
浏览次数：6 次浏览
发布日期：2026-10-09 17:32:12
本文链接：https://www.ybb.press/ebpf-tech/16303.html

上一篇 > eBPF深度实战：从内核探针到可观测性革命
下一篇 > 深入 eBPF：Linux 内核的可编程革命 —— 从数据包过滤到云原生观测

eBPF 技术深度实战：重构 Linux 内核可观测性与网络的编程范式

评论列表共有 0 条评论

发表评论取消回复

eBPF 技术深度实战：重构 Linux 内核可观测性与网络的编程范式

eBPF 技术深度实战：重构 Linux 内核可观测性与网络的编程范式

Linux Netlink 协议深度实战：用户空间与内核通信的主力协议

eBPF 与 XDP：Linux 内核网络栈的范式革命与高性能数据包处理实战

Linux eBPF 深度剖析：从字节码虚拟机到内核可编程基础设施

评论列表 共有 0 条评论

发表评论 取消回复

评论列表共有 0 条评论

发表评论取消回复