2. eBPF基础回顾：程序类型、Map、Helper函数、验证器与JIT编译器
在深入租户隔离架构之前，必须重新夯实eBPF的五大核心支柱。本章从程序类型、Map、Helper函数、验证器与JIT编译器四个维度展开，为后续的准入控制策略与隔离设计提供底层技术语言。
2.1 eBPF程序类型与挂载点
eBPF程序类型决定了程序可以挂载到内核的哪个事件点，以及可以访问哪些上下文数据。截至Linux 6.x内核，已有超过40种程序类型，按功能域可划分为以下几类：
| 分类 | 典型程序类型 | 挂载点/事件 | 租户隔离关注点 |
|---|---|---|---|
| 网络 | BPF_PROG_TYPE_XDP, BPF_PROG_TYPE_SCHED_CLS, BPF_PROG_TYPE_CGROUP_SKB | 网卡驱动层、TC入/出方向、cgroup网络 | 租户网络流量隔离、带宽限制 |
| 跟踪 | BPF_PROG_TYPE_KPROBE, BPF_PROG_TYPE_TRACEPOINT, BPF_PROG_TYPE_PERF_EVENT | 内核函数入口/出口、静态跟踪点、性能计数器 | 租户行为审计、异常检测 |
| 安全 | BPF_PROG_TYPE_LSM, BPF_PROG_TYPE_SOCKET_FILTER | LSM钩子（security_*）、socket系统调用 | 强制访问控制、系统调用过滤 |
| 容器/调度 | BPF_PROG_TYPE_CGROUP_DEVICE, BPF_PROG_TYPE_CGROUP_SYSCTL | cgroup设备白名单、sysctl参数变更 | 设备访问隔离、内核参数隔离 |
关键认知： 程序类型决定了eBPF的“视野”范围。在租户隔离场景中，cgroup关联的程序类型（如BPF_PROG_TYPE_CGROUP_SKB）天然具备进程组边界，是实现租户级网络与设备隔离的首选挂载方式。
2.2 eBPF Map：内核态与用户态的共享数据桥梁
eBPF Map是内核态eBPF程序与用户态控制面之间交换数据的核心结构。Map类型决定了数据的组织方式与并发语义。
2.2.1 常用Map类型对比
| Map类型 | 数据结构 | 典型用途 | 隔离场景适用性 |
|---|---|---|---|
| BPF_MAP_TYPE_HASH | 哈希表（键值对） | 配置查找、会话状态 | 高：每个租户独立哈希表 |
| BPF_MAP_TYPE_ARRAY | 固定大小数组 | 计数器、统计指标 | 中：需通过索引映射租户ID |
| BPF_MAP_TYPE_LRU_HASH | LRU淘汰哈希表 | 连接跟踪、缓存 | 高：自动淘汰非活跃租户条目 |
| BPF_MAP_TYPE_PERCPU_HASH | Per-CPU哈希表 | 高性能计数器 | 中：需注意CPU级数据合并 |
| BPF_MAP_TYPE_RINGBUF | 环形缓冲区 | 事件日志、审计记录 | 高：支持按租户标记事件 |
隔离设计提示： 在租户隔离架构中，建议为每个租户创建独立的Map实例，或在共享Map中使用租户ID作为键前缀。前者隔离性更强，后者资源利用率更高。后续章节的准入控制策略将围绕这两种模式展开。
2.3 eBPF Helper函数：受限的内核API
Helper函数是eBPF程序与内核交互的唯一合法途径。每个程序类型都有其可调用的Helper函数白名单，这构成了eBPF安全模型的第一道防线。
2.3.1 常用Helper函数分类
- 数据获取类：
bpf_get_current_pid_tgid()、bpf_get_current_cgroup_id()、bpf_get_current_uid_gid()—— 用于识别当前进程所属的租户上下文。 - Map操作类：
bpf_map_lookup_elem()、bpf_map_update_elem()、bpf_map_delete_elem()—— 所有Map访问必须通过这些函数，验证器会检查Map类型与键值类型是否匹配。 - 网络操作类：
bpf_skb_load_bytes()、bpf_skb_store_bytes()、bpf_redirect()—— 用于网络数据包的解析与转发。 - 辅助输出类：
bpf_printk()、bpf_perf_event_output()—— 调试与事件上报。
安全约束： Helper函数不可动态加载。所有Helper调用在编译时即被验证器固定。这意味着租户隔离策略中使用的Helper函数必须在eBPF程序加载前就确定，无法在运行时动态扩展。这是设计准入控制策略时必须考虑的限制。
2.4 eBPF验证器与JIT编译器：安全与性能的双重保障
验证器与JIT编译器是eBPF程序从用户态字节码到内核态安全执行的关键环节。理解它们的工作原理，有助于设计出既安全又高效的租户隔离策略。
2.4.1 验证器工作流程
- CFG（控制流图）构建： 验证器将eBPF字节码转换为有向无环图（DAG），确保不存在不可达代码或循环。
- 类型检查： 检查每个指令的操作数类型是否与寄存器类型匹配，特别是Map键值类型的静态验证。
- 路径敏感分析： 模拟所有可能的执行路径，确保不会出现空指针解引用、越界访问或无限循环。
- Helper白名单检查： 确认程序调用的所有Helper函数都在其程序类型的允许列表中。
- 复杂度限制： 检查指令数（上限100万条）和栈大小（上限512字节），防止拒绝服务攻击。
2.4.2 JIT编译器的作用
JIT（Just-In-Time）编译器将验证通过的eBPF字节码转换为目标CPU架构的原生机器码，消除解释执行的开销。对于x86_64架构，JIT编译后的eBPF程序执行效率接近原生内核函数。
性能数据： 经过JIT编译的eBPF程序，其执行延迟通常在纳秒级（例如XDP程序在10Gbps线速下每个包处理时间约50-100ns）。这使得在租户隔离场景中，eBPF可以作为数据平面的核心执行引擎，而不会成为性能瓶颈。
2.5 核心组件关系图
下图展示了eBPF程序从编写到执行的全链路，以及各组件在租户隔离架构中的角色：
2.6 本章小结
- 程序类型 决定了eBPF的挂载点与上下文，cgroup关联类型是租户隔离的首选。
- eBPF Map 是数据共享的核心，租户隔离推荐使用独立Map实例或租户ID前缀方案。
- Helper函数 是受限的内核API，必须在加载前确定，无法动态扩展。
- 验证器 通过CFG构建、类型检查与路径分析确保程序安全；JIT编译器 将字节码编译为原生机器码，提供纳秒级执行性能。
下一阶段预告： 在掌握了eBPF基础组件后，第3章将进入租户隔离的威胁模型与安全需求分析，从攻击者视角审视多租户场景下的内核攻击面，并推导出准入控制策略的设计目标。