eBPF 在主机与卸载路径之间还能保证完整中介吗？

一台主机最初只在软件路径上执行网络安全策略。为了降低 CPU 开销，运维人员后来把一部分规则卸载到 SmartNIC 或 DPU。命中硬件规则的数据包可以留在设备快速路径上，未命中的流量则可能经过 representor 回到主机慢速路径。设备重置、规则不受支持或者 XDP 模式切换，又会让流量重新改变路线。

安全要求没有因此改变。凡是应该受策略约束的数据包，都必须经过至少一个能够执行当前策略的可信执行点。系统安全里的 complete mediation，也就是这里所说的“完整中介”，关心的正是这一点。

问题在于，“程序已经成功加载”并不能证明这个条件成立。主机上的 BPF 程序可以正常存在，但一部分流量可能已经在硬件交换；某条规则可以成功卸载，另外一些路径却在软件回退。主机和设备即使都能执行 drop 或 redirect，它们可用的 helper、map、metadata 与更新边界也可能不同。

本文的核心判断是：异构 eBPF 网络里的完整中介应该被表达为一个“路径覆盖”不变量。 对每一类可达的数据包路径和每一个策略 generation，系统都应该能指出至少一个可信的 enforcement point，并证明它能看到策略所需的上下文、使用语义等价的状态，而且当这个执行点消失时存在明确的安全回退方式。

这和此前的 “异构系统里的 eBPF 到底应该运行在哪里？” 不同。那篇报告讨论的是多个后端都合法时，planner 应该怎样选择执行位置；本文假设位置已经选好，再问这些位置组合起来以后，是否仍覆盖了所有需要受安全策略约束的流量路径。

它也不同于 授权撤销。撤销问题假设数据包已经经过策略判断，研究旧的 allow 还能在缓存状态里存活多久。完整中介先问一个更基础的问题：这个包是否真的经过了能够执行当前授权规则的 enforcement point。

卸载本身就会产生多条数据包路径

Linux 的 representor 文档把这种分裂写得很直接。Network Function Representor 既是控制设备中 VF/SF 的句柄，也为没有命中硬件快速路径规则的流量提供慢速路径。TC filter 等规则可以通过 representor 安装，再被硬件卸载。Linux 文档的设计目标是：除了性能，规则在软件执行还是硬件执行不应改变数据包的行为。这个目标本身就说明，安全策略需要同时面对硬件 fast path 和软件 slow path。参见 Linux Kernel 的 Network Function Representors。

设备能力也不是统一的。Linux 当前的 netdev generic-netlink 规范 会暴露每个 netdev 的 XDP feature，包括基本 action、redirect、AF_XDP zero-copy 和 hardware offload 支持。控制面因此可以知道两个接口拥有不同的执行能力，但“这个设备支持硬件 XDP”依然不是“所有策略流量都经过硬件 XDP”的证明。

Cilium 当前的 BPF toolchain 文档给出了更具体的运行差异。XDP 可以使用 native driver、generic 或 SmartNIC hardware offload 三种模式。xdpoffload 会让程序直接在网卡上执行，但并不是所有 BPF map 与 helper 都可用。普通 xdp 在 native XDP 不受支持时可以回退到 generic XDP，而明确指定 xdpdrv 则可以要求 native 模式，否则直接失败。不同 XDP mode 之间也不能原子切换。参见 Cilium 的 BPF development toolchain。

设备侧执行确实有性能价值。hXDP 在 OSDI 2020 展示了 FPGA NIC 上的 XDP 执行，并在论文评测的 workload 中显著降低了转发延迟。真正缺少的不是“该不该卸载”，而是控制面在把更快的路径当成安全等价路径之前，究竟应该证明什么。

完整中介首先是覆盖问题，而不是 placement 分数

Placement planner 可以比较延迟、CPU、状态跨域开销和设备能力。安全策略必须先回答另一个问题：现在有哪些可达的数据包路径？每一条路径由哪个执行点负责？

设想一台机器有物理 uplink、两个 VF、对应的 representor、设备内部 eSwitch fast path，以及主机软件路径。一次策略更新至少可能影响以下几类流量：

• uplink 到 VF，直接命中硬件规则；
• uplink 到 VF，硬件 miss 后进入 representor slow path；
• VF 到 uplink，在硬件和主机 fallback 之间切换；
• VF 到 VF 或 hairpin 流量，可能完全留在设备 switch 内；
• 经过 XDP redirect 或 AF_XDP 的流量；
• 卸载规则替换、撤回或设备 reset 后恢复期间的数据包。

不同设备和部署的实际路径不一样。也正因为如此，在 eth0 上看到一个 BPF attachment 并不能推出以上流量都以同一种方式经过它。

可以把一个 path class 定义为决定 enforcement 位置的一组事实，例如 source port/function、destination class、方向、switching domain、offload mode 和 fallback。对于策略 generation g，每个可达 path class p 至少要映射到一个 enforcement point e，并满足：

1. e 已经为 generation g 生效；
2. e 能看到策略需要的上下文；
3. e 对这类路径实现与目标策略等价的 verdict；
4. 它读取的状态是 authoritative，或者其一致性落在明确允许的边界内；
5. 如果 e 消失，流量会进入另一个已覆盖的执行点，或者在安全策略要求下停止通过。

这并不要求所有后端执行完全相同的 BPF bytecode。SmartNIC rule、host TC program 与 XDP program 可以是不同的编译结果。真正需要保持的是：对于同一个 path class 和 policy generation，安全决策仍然等价。

生产环境也不需要为每个包保存完整 witness。大部分拓扑覆盖关系可以在部署和更新时验证，只保留紧凑的 generation 与 coverage 证据。逐包证据更适合 benchmark、抽样审计和故障复现。

为什么“部署成功”仍然不够

一次成功的 load 或 offload 只能回答局部问题：某个 backend 接受了某个程序或规则。完整中介是所有可达路径上的全局性质。

例如，uplink 到 VF 的 deny rule 已经成功下发到硬件，主机控制面也报告新 generation ready。但是 VF-to-VF 流量可能走另一个 eSwitch 路径，而控制器从未把它放进 coverage model。两个局部操作都成功了，全局策略仍然有洞。

反过来也可能发生。设备失去 offload rule 后，流量开始通过 representor 回到主机。若 host slow path 已经运行同一 generation，fallback 可以是安全的；若主机程序落后一代，同一个包会仅仅因为硬件状态变化而得到不同 verdict。

这与 多租户网络策略组合 中的 authority provenance 有关联，但并不重复。Policy composition 决定“哪一个 owner、哪一条规则应该做决定”；complete mediation 决定“每条实际可达路径是否真的经过了能够执行这个决定的位置”。

现有研究还缺什么

Attachment 与 offload 状态没有直接证明拓扑覆盖

Linux 能告诉用户态一个 netdevice 是否支持 XDP hardware offload，控制面也可以查询程序和 flow rule 是否成功安装。Representor 暴露 slow path，也可以作为硬件 rule 的控制句柄。这些信息都很重要。

缺少的是把 packet topology 与这些局部状态连接起来的统一断言：策略 P 的 generation G 已覆盖全部可达 path class。 没有这个断言时，运维人员只能从一组 per-device 状态推测完整中介是否成立。

如果 SR-IOV 配置、hairpin、redirect、offload rule 或拓扑变化能够制造一条绕过所有预期 enforcement point 的可达路径，这个缺口就是真实的。最直接的验证方式是 topology mutation benchmark：不断改变这些条件，再比较 controller 声称的 coverage 与实际 packet path。

软件与硬件 verdict 等价通常只在局部被假设

Linux representor 语义希望 TC rule 在硬件 offload 和软件处理时保持相同行为，XDP offload 也从一个可在设备执行的程序出发。但是完整网络策略可能依赖 map state、metadata、helper 行为或 policy generation，而这些条件并不天然在不同 backend 中完全一致。

需要的不是证明任意两个 BPF 程序形式等价。更可落地的做法是让每个 backend artifact 声明自己实现的 policy operation 与 state generation，并只对允许该 backend 覆盖的 packet class 做差分验证。

这很重要，因为显式“不支持”通常比静默产生不同 verdict 更安全。测试可以把同一组 policy-relevant packet 和状态 generation 同时送给 software 与 offload implementation，只要 externally visible verdict 超出允许边界就拒绝激活。

Fallback 与 reset 缺少“覆盖空窗”指标

卸载系统必须处理 rule replacement、device reset、driver reload、capability loss 和 mode switch。很多实现可以回退到软件或者重新安装 hardware state，但安全问题是时间性的：transition 期间是否存在某个时刻，一条可达路径没有当前 enforcement point？

这里缺少的指标是 coverage gap，不只是 recovery time。Benchmark 应同时记录旧的或未覆盖路径最后一次接受数据包的时刻，以及新的合法 enforcement point 第一次接管的时刻。一个系统即使恢复很快，只要中间放过一个不该放行的包，完整中介仍然被破坏。

兼具学术价值与生产价值的方向

1. 把可达路径编译成 enforcement coverage plan

缺口。 Controller 已经知道 interface、representor、XDP capability 和单个 offload rule 的状态，却很少把这些信息转化为“所有策略相关路径都被覆盖”的显式 proof obligation。

机制。 构建一个小型 topology compiler，发现或接收 host port、VF/SF、representor、eSwitch 关系、routing/redirect domain，以及可用的 BPF/offload capability。它枚举 policy-relevant path class，再为每一类分配一个或多个 enforcement point。只要某个可达 class 没有满足所需 context、state version 与 verdict 能力的执行点，activation 就失败。

Coverage 与 optimization 应该分开。Placement layer 可以在合法执行点中选成本最低的一个，但不能通过优化目标删除 coverage requirement。

与现有工作的差别。 之前的 heterogeneous placement 报告 提出 target manifest 与 planner，用于多个合法执行位置之间的选择；这里增加的是另一种不变量：这些位置组合起来必须覆盖实际可达的 network-path graph。单个 backend 再完美，如果流量可以绕过它，安全性仍然不成立。

可实现产物。 一套公开 path-model schema、Linux netlink/devlink adapter、representor 与 XDP capability discovery，以及一个能够输出 coverage map 与 uncovered-path explanation 的 checker。

评测。 在包含 uplink、VF/SF、representor、host、XDP 与 hardware-offload 的物理/虚拟拓扑上，反复改变 routing、offload support、VF 关系和 redirect rule。对比 per-device attachment inspection 与 host-only baseline，测量 uncovered-path detection、false alarm、plan 计算耗时，以及最终 enforcement plan 的吞吐成本。

学术价值。 它研究的是 reference monitor 被拆到多个 programmable network location 后，complete mediation 应如何被证明。

生产价值。 CNI、service-mesh datapath、firewall controller 或 SmartNIC 管理面可以在 rollout 前拒绝一份留下未覆盖路径的配置，而不是等事故发生后再发现。

失败条件。 如果真实部署中的路径集合很小且固定，现有 kernel/device API 已经能无歧义地覆盖全部路径，而且 topology fuzzing 找不到隐藏 class，那么通用 compiler 不值得引入。

2. 让 policy generation 在 offload 与 fallback 之间连续

缺口。 一条路径可以始终“被某处检查”，但在 hardware 与 software 之间切换时落到不同的 policy generation。

机制。 让每个 enforcement domain 输出一个紧凑状态：policy identity、generation、覆盖的 path class、backend mode 与 readiness。Rollout barrier 只有在每个必需 path class 至少拥有一个 target-generation 的 ready enforcement point 时才完成。如果设备失去 offload rule，controller 只有在 host 侧同一 generation 已经生效后才允许流量 fallback；否则对 policy-sensitive traffic 暂停或 fail closed。

这个方案不要求同步删除所有旧规则。核心性质是 packet 在 enforcement point 之间迁移时不能发生不可见的 generation downgrade。

与现有工作的差别。 授权撤销报告 追踪的是 persistent state 中 stale authority 何时失效；这里追踪的是 traffic 从硬件走到软件时，负责做决定的 enforcement point 本身是否保持 generation 连续。

可实现产物。 一个消费 BPF link/program state 与 netdev/devlink/offload status 的 coordinator，输出 per-path generation readiness，并驱动两阶段 activation 或 fail-closed fallback。

评测。 在持续 policy update 的同时强制 hardware rule eviction、NIC reset、representor fallback、controller restart 和 XDP mode change。比较 best-effort offload、host-only enforcement 和 generation barrier，记录 unauthorized packet、wrong-generation verdict、recovery time、update latency 与 steady-state packet cost。

学术价值。 这个机制把“fallback 应该是安全的”变成可测试的 temporal safety property。

生产价值。 运维人员可以获得明确的 upgrade/device-fault readiness，而不是假设 software 与 hardware 恰好按正确顺序收敛。

失败条件。 如果现有 control plane 在全部 fault transition 中已经保持 hardware/software generation 同步，或者 host-only failback 的成本足够低，那么更简单的方案应该获胜。

3. Benchmark 应直接测 policy escape，而不只测 offload 吞吐

缺口。 Offload 评测通常问设备节省了多少 CPU 或 latency；安全评测又常默认测试包已经经过目标 enforcement point。两者都没有直接测“路径变化时是否出现未中介流量”。

机制。 构建 ground-truth path-escape harness。Harness 生成预先知道正确 verdict 的 packet class，强制它们经过 hardware hit、hardware miss、representor slow path、VF-to-VF/hairpin、不同 XDP mode 与 fault transition，同时记录每个包实际走过的路径和处理它的 policy generation。

主要结果不是 PPS，而是三类 packet 的数量与时间：没有合法 enforcement witness 就被接受、由过期 generation 接受、或者与 reference policy 给出不同 verdict。

与现有工作的差别。 hXDP 等研究说明 device-side execution 有明确性能价值。这个 benchmark 保留性能指标，但增加专门让 incomplete mediation 暴露出来的 correctness workload。

可实现产物。 可复现网络拓扑、traffic generator、fault injector、reference policy interpreter 和 trace format，可同时用于 kernel、CNI、SmartNIC 与 DPU 实现。

评测。 使用完全相同的 policy、packet load 和 update schedule，对比 host-only、best-effort offload 与 coverage-aware rollout。在 throughput 和 CPU 之外报告 policy escape、stale-generation verdict、detection latency 和 recovery behavior。也应包含所有方案都应该打平的简单拓扑，让新机制在“没有真实问题却增加 overhead”时受到惩罚。

学术价值。 它提供了传统 throughput 与 rule-install 指标没有覆盖的 systems-security property 测量方法。

生产价值。 Vendor 和 operator 可以验证硬件加速路径在 update 与 fault 期间是否仍保持安全契约，而不只是 steady state 能跑多快。

失败条件。 如果多个独立实现都能在 adversarial path transition 中做到零 policy escape，而且 coverage-aware mechanism 也没有改善 detection 或 recovery，那么现有 abstraction 可能已经足够。

哪些结果会改变这个判断？

本文的判断建立在两个前提上：异构网络里存在无法从单个 attachment/offload 成功状态可靠推断的可达路径；hardware 与 software policy generation 在真实更新或故障过程中存在短暂分叉的可能。

最有力的反例是一套 production-grade control plane：它已经能导出完整的 path-to-enforcement map，证明 hardware/software 的 policy generation 等价，并且在 topology change、offload withdrawal 和 device reset 下，通过 adversarial benchmark 仍然没有任何 uncovered packet 或 stale-generation packet。若这样的证据成立，真正缺少的可能只是标准化接口与统一测量，而不是新的 runtime protocol。

成本同样是边界。如果拓扑足够简单，所有 policy-relevant path 都可以一直经过一个 host enforcement point，而且性能损失可以接受，那么分布式 coverage coordination 就是错误的设计。Complete mediation 是必须保留的性质；heterogeneous enforcement 只有在带来足够的性能或 locality 收益时才值得增加额外状态。

因此，下一步最有价值的实验不是再做一次 peak-throughput 对比，而是拿一个真实的 host+SmartNIC 或 host+DPU 部署，枚举全部可达 packet path，强制 policy update 与 device failure，然后对每一个被接受的包回答一个二元问题：当前哪个 enforcement point 授权了这个包？系统能不能证明不存在一条没有 enforcement point 的可达路径？

参考资料

• Linux Kernel documentation，Network Function Representors。
• Linux Kernel documentation，netdev generic-netlink specification。
• Cilium documentation，BPF development toolchain and XDP operation modes。
• Brunella 等，hXDP: Efficient Software Packet Processing on FPGA NICs，OSDI 2020。
• Eunomia Daily Report，异构系统里的 eBPF 到底应该运行在哪里？。
• Eunomia Daily Report，一次已经撤销的授权，能在 eBPF 数据路径里存活多久？。
• Eunomia Daily Report，多租户网络策略应该怎样在 eBPF 数据面里组合？。