IOValve 精读：把沙箱边界推到网线上

Posted on Edited on Views: Word count in article: 10k Reading time ≈ 19 mins.

把 I/O 沙箱的执法点从 CPU 核挪到一块与主机物理隔离的 DPU 上，出网流量全都要经过它——加密、阻断，再整形成恒定节拍（固定大小的包、固定间隔，没真数据就发假包）。于是沙箱里的恶意代码没有可调的信道。代价是 LLM 微调耗时增加 2.1%～4.1%，批量推理吞吐下降 1.4%。

论文：IOValve: Leakage-Free I/O Sandbox for Large-Scale Untrusted Data Processing（CCS ’25，2025 年 10 月，台北）

作者：Sangho Lee、Jules Drean、Yue Tan、Marcus Peinado（Microsoft Research / MIT / Princeton）

代码量：约 2500 行 C（adapter、puller/pusher、regularizer、兼容层、NCCL 网络插件）；无开源产物

前面几篇读的都是同一条链路上的「拿」：Hermes（USENIX Security 2021）用商用协议分析仪从明文 PCIe 流量里 lossless 重建整个 DNN；PCIeHardwareMitM（Microprocessors & Microsystems 2020）把一块 FPGA 插进主机与外设之间，读包、改包、复制包。

这一篇换了个立场，而且是反过来的立场：它不偷东西，它修墙。修墙的位置很特别——不在 CPU 核里，不在 hypervisor 里，而是在一根网线前面，由一块独立的、和主机物理隔离的可编程网卡执行。它给这套设计的卖点只有四个字：leakage-free（无泄漏）。

这篇要盯住的就是这四个字：它凭什么敢这么说，这个「无」的边界画在哪里，以及代价是多少。

不过这篇容易读乱的地方不在它做了什么，而在谁在做：一台物理主机、一块挂在它旁边的独立网卡、一个看得见网线的第三方，三方的信任状态完全不同，同一条 PCIe 上两边的打算也正好相反。所以下面先花一节把出场角色认全，再顺着「谁防谁」去看设计。

📚 基本概念速读

名称 定义 记忆点
TCB（Trusted Computing Base，可信计算基） 一个系统里”必须被信任、一旦它坏了整个安全性就没了”的那部分 这篇的目标就是缩小 TCB，把云厂商和训练软件都踢出去
机密计算（Confidential Computing） 用处理器硬件把数据和使用它的软件隔离开，让云厂商也看不到 常见形态是 enclave（如 Intel SGX）或机密虚拟机（CVM）
CVM（Confidential Virtual Machine） 由处理器硬件保护的整台虚拟机，hypervisor 也看不进去 比 enclave 粗一档，但仍然是同一颗 CPU 内的细粒度共享
沙箱（Sandbox） 把所有会碰到机密数据的代码关进一个框里，只留一条受控的信息出口 本文的框是一整台物理主机，出口是一根网线；注意文中「沙箱」有时指框（那台主机），有时指锁（DPU 上的监控器）
隐蔽信道（Covert channel） 恶意代码主动往外传消息的通道，不依赖本来有没有设计出口 与侧信道（被动观测）相对；本文的对手是它
DPU（Data Processing Unit，也叫 IPU） 一块独立的、自带 CPU 和网卡的”小电脑”，通过 PCIe 挂在主机上，替主机做网络与存储 云厂商本来就用它卸载网络加密、健康监控；本文把沙箱监控器放上去
BlueField-3 NVIDIA 的一款 DPU：内含一颗 RDMA 网卡（RNIC）、一颗 Arm CPU、一个 PCIe switch、内存与存储 本文的原型平台
RNIC（RDMA-capable NIC） 能在不打扰对端 CPU 的前提下直接读写对端内存的网卡 “one-sided”远程读写就靠它
RDMA（Remote Direct Memory Access） 一台机器不经对方 CPU 直接读写对方内存 比常规收发（Send/Recv）少一次 CPU 参与
RoCEv2 把 RDMA 报文装进 UDP 包、跑在以太网上的协议 本文用它，因为以太网加密方案现成
IPSec 一套给 IP 包做认证与加密的协议 本文拿它的硬件加速来加密 RDMA 报文
traffic regularization（流量整形） 不管上层有没有数据要发，都按固定节奏往网上发固定大小的包 本文的核心武器；不够就发假包
BuFLO 一种经典的”恒定速率”抗流量分析方案 本文的整形思路源于它，区别是把”安全但慢”做成了实用
流量分析（traffic analysis） 不解密、只看包的大小与时间间隔，就能推断内容或行为 整形要防的就是它
AllReduce / AllGather 多机训练里的”集合通信”操作：所有节点把各自的梯度汇总或分发 这类通信的流量天然接近匀速，是本文整形能便宜做的前提
NCCL NVIDIA 的多卡多机通信库，PyTorch 的分布式训练底层就是它 本文要插的就是它的网络插件

🎭 出场角色：谁是谁、谁信谁

这篇的设定里只有五个角色，先把它们摆在一起看。后面每一节讲的，都是其中某一个在干什么、防谁、被谁防。

角色 是谁 可信吗 负责什么
数据所有者（用户） 手里有敏感数据、想训大模型又不想泄密的一方（政府、航空、金融、军工这类客户） 可信，也是唯一着急的人 把数据交给别人代跑；提供自己指定的软件镜像，并验证 DPU 的远程证明
主机（host） 一台裸金属服务器，Linux / CUDA / NCCL / PyTorch / 训练代码全在上面 不可信 干活：真正做矩阵运算、真正碰到机密数据的那台机器
DPU 挂在主机 PCIe 上的一块独立小电脑（BlueField-3），同时也是这台节点唯一的网卡 可信，系统里唯一的 TCB 执法：主机与外界之间所有数据往来都从它手里过——加密、阻断、整形
对端节点（peer node） 同一个训练任务里的另一台机器，结构完全一样 可信（与本地对称） 通信的另一端
云网络运营商 拥有并观测那根网线的第三方 不可信（观察者，不是攻击者） 它什么都不用做，光是能看见网线上的每个包就够了

三个可信角色串成一条直线：数据所有者出镜像 → DPU 证明自己跑的是用户指定的监控器 → DPU 从网络启动主机。 信任是从 DPU 这一端长出来的，主机在链条末端，从一开始就被当成不可信。

两个不可信角色则要分开看，因为它们干的事完全不同：

  • 主机里的代码会主动搞事——它想把数据偷出去，会主动找信子往外递。这就是隐蔽信道（covert channel）。
  • 云网络运营商只是在看——它不篡改任何东西，但网线上每个包的大小和时间间隔它都看得见。这是流量分析（traffic analysis）。

这两件事要分开防：加密防的是「看不懂内容」，整形防的是「看不出节奏」。 论文承诺的 leakage-free，主要是对着后者说的。

还有两个角色被明确排除在威胁模型之外：能物理接触硬件的人（拆机箱、在链路上插探针、改主板配置），以及同租户（所以要求 DPU 由单租户独占）。边界一节还会回到它们。

最后一个容易混的地方：「沙箱」这个词在文中指两样东西——框是那台主机（所有会碰数据的代码都关在里面），锁是 DPU 上的那个监控器（sandbox monitor）。下文说「框」，指的是主机；说「监控器」，指的是 DPU 上的执法软件。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
┌───────────────────────────────────────┐
│ untrusted host  (the box)             │  ← 干活的那台机器，训练代码与机密数据都在里面
│ Linux / CUDA / NCCL / PyTorch / LLM   │
└───────────────────┬───────────────────┘
                    │ PCIe    ← 主机唯一能碰到 DPU 的通道：能挤流量、能递时序
┌───────────────────┴───────────────────┐
│ IOValve DPU (BlueField-3)             │  ← 唯一可信的一方，sandbox monitor 在这里执法
│ sandbox monitor: encrypt/block/shape  │
└───────────────────┬───────────────────┘
                    │ Ethernet (RoCEv2 + IPSec)
     ══════════════════ the only wire ══════════════════
                    │                            ↑
                    ↓                            └── cloud network operator：不可信的观察者，站在这里看每个包
                    peer node  (host + DPU)   ← 同一个训练任务里的另一台机器，结构相同

🧭 主机：被关进框里的那台机器

先看框里那个角色。它要干的活、以及它为什么不可信，决定了后面所有设计。

它要干的活，本身就要求数据出门。 训练和微调大模型需要巨量算力——Meta 训 Llama 3 用了两个各含 24,576 张 NVIDIA H100 的集群；全量微调 Llama 3.1 405B 需要 3.25 TB 显存，折合 40 多张 H100。政府、航空、金融、军工这类客户很在意数据机密，但自建这个规模的算力不现实，只能外包。

外包之后，跑在这台主机上的整套软件栈就都不可信了。 机密计算解决的是「云厂商不可信」：把数据放进 enclave 或 CVM，连 hypervisor 都看不进去。但它没解决另一半——处理数据的代码本身不可信。现代大模型训练栈除了操作系统、GPU 驱动、CUDA，还有 NCCL（通信）、Alpa（模型并行）、PyTorch / TensorFlow（训练框架）、Ray / Horovod（分布式调度）、数据管道、日志监控……横跨几十上百个开源与闭源组件，而供应链攻击 2022 年同比增长 633%、报告了 8.8 万起。指望「这一堆代码都没问题」是不现实的。

沙箱就是对这一环的回答： 把所有会碰机密数据的代码全都关进一个框，然后只留受控的信息出口。这相当于一种粗粒度的强制访问控制，好处是那堆训练代码不再需要被信任。请注意这个框的尺寸——它不是围着某个进程画的，而是围着一整台物理主机画的。

但一个不可信的角色关进框里，也还是握着两把能作弊的钥匙：

  • 第一把通向隔壁的 DPU。 主机和 DPU 之间连着一条 PCIe。论文这样描述这条路怎么被利用：假设一个良性进程正把 DRAM 里的通信缓冲发给远端，网卡通过 DMA（直接内存访问，让设备绕过 CPU 直接读写内存的机制）去读 DRAM——那么一个同样能访问 DRAM 的恶意进程，就可以通过挤压内存带宽来改变网卡的 DMA 速度，从而在良性的传输上调制出信息。这条信道根本不需要恶意代码有网络权限，也不需要它碰到那份数据。
  • 第二把通向网线。 就算数据离开主机时不带任何标签，主机也能靠「什么时候发、发多少」在流量节奏上写信。

第二把钥匙还有另一层麻烦：即使主机不主动写信，光看这根网线上的流量形状，别人也能看出它在干什么。 论文对现状的判断是：

存储型隐蔽信道（把秘密藏在某个共享状态里）有人处理，时间型隐蔽信道几乎被普遍排除在威胁模型之外。

原因也不难理解：几十年来，在细粒度共享硬件的条件下消除时间信道被认为是不可能的——两个进程共享同一颗 CPU 的缓存、同一条内存总线、同一个分支预测器，恶意方只要调节自己对共享资源的占用，就能让良性的传输快一点或慢一点，这本身就是一个比特。

于是就有了这篇的转向。 既然「细粒度共享下堵不住」，那就换一个粗得多的边界：不要围着进程画框，围着一整台物理主机画框。这台主机与外界的唯一连接是一根网线，网线那头的云网络运营商能看到的，只有这根线上的包。论文的原话是：

大规模计算恰好适合这么做——它本来就需要一整批机器，而机器之间的通信模式通常很规则。

👀 云网络运营商：看得见每一根网线上的包

顺着那根网线看过去，线那头站着第二个威胁方，而它和主机完全不同——它什么都不用做。

  • 它能看到什么： 网线上的每一个包，以及包的大小、方向、时间间隔。它不用解密，也不用攻破任何组件。
  • 它的威胁叫什么： 流量分析（traffic analysis）——不解密，只看包的大小与时间间隔，就能推断内容或行为。
  • 它是整形存在的理由： 论文承诺的 leakage-free 主要是给它看的。不管框里的主机在干什么，这根线上的包都得长成同一个样子——固定大小、固定间隔，没真数据就拿假包顶上。这一步由 DPU 上的 regularizer 做，下一节细说。

顺着这一节也能看出论文为什么挑了多机训练当战场：AllReduce / AllGather 这类集合通信的流量天然接近匀速，整形几乎不额外花钱。而 LLM 对话那种 prompt 与 response 长度高度可变的场景，整形会立刻变贵——这一点论文自己在 Limitations 里承认了，边界一节再展开。

🔒 DPU：唯一被信任的执法者

现在轮到夹在两个威胁方中间的那块硬件。

DPU 是一块独立的、自带 CPU 和网卡的”小电脑”，通过 PCIe 挂在主机上，替主机做网络与存储——云厂商本来就用它卸载网络加密、健康监控。本文的原型是 NVIDIA 的 BlueField-3：内含一颗 RDMA 网卡（RNIC）、一颗 Arm CPU、一个 PCIe switch、内存与存储。

它凭什么可信？ 因为它是整个系统里唯一的 TCB（必须被信任、一旦坏了整个安全性就没了的那部分）。设计原则只有两句：让沙箱的接口尽可能简单，让框里的代码和执法代码之间有强物理隔离。具体落在三个位置上：

  • 接口只有两个：send 和 receive。除这两个之外，框内框外没有其它接口，而且这两个接口的行为不取决于框内做了什么（这一点看整形时会更清楚）。
  • 执法者和被执法者物理隔离：沙箱监控器跑在 DPU 上，主机跑在 CPU 上，两者是两个独立的计算机，只通过 PCIe 相连。
  • 上界被压到一根网线：恶意代码想往外传，能用的信道只剩”调制这根网线上的流量”。剩下的任务，就变成”如何让这根线上的流量不可被调制”。

这一步是整个设计里最漂亮的地方——它把”不可能的任务”（在共享缓存的核里堵住时间信道）换成了”难但可做的任务”（把一根网线上的流量整形到匀速）。

🧱 开局：先给 DPU 立四条硬件要求

把监控器放到 DPU 上之后，新的问题立刻出现：DPU 和主机之间还连着一条 PCIe，主机完全可以去挤这条链路、用时序往 DPU 递消息。所以论文给 DPU 立了四条硬件要求，每条都是为了堵一个具体的口子：

要求 要堵的口子
DPU 必须是该节点唯一的网络设备 框里再插一块网卡，就等于多了一条出口。（主板集成网卡、USB 网卡也算，论文把这类情况归入”物理攻击”，不在威胁模型内）
DPU 必须能忽略主机发来的管理命令（刷固件、暴露硬件组件、改网络配置） 否则被攻陷的主机直接把 DPU 刷掉就行了
DPU 必须能重新部署主机（PXE 网络启动、控制 BMC 重置节点） 需要一个干净的起点；主机上的任何状态都不能被继承
DPU 必须由单租户独占 避免同租户之间的侧信道

这四条里，前三条 BlueField 这类 DPU 已经具备（论文引了它的安全启动特性）。再加上远程证明和远程启动，就得到了一个完整的开局：用户把自己的镜像交给 DPU，DPU 证明自己跑的是用户指定的监控器，然后再由 DPU 从网络启动主机。 从这一刻起，主机里的一切都是不可信的，包括那块负责搬数据的 adapter，而监控器本身是可信的。

🌊 对付主机：在 PCIe 上让拥塞传不过去

开局之后的第一条战线，冲着主机去。主机能用来写信的那个变量是拥塞，所以 IOValve 的解法是空间上的隔离：把通信缓冲从主机内存挪到 DPU 内存里，恶意代码在物理上就够不着它。要做到这一点，需要同时满足三件事：

  • 主机 CPU（也就是它的 DMA 引擎）不能访问 DPU 内存；
  • 网卡（RNIC）不能访问主机内存；
  • 主机 CPU 不能访问或拥塞”网卡 ↔︎ DPU 内存”这条链路。

但这三件事做到之后，主机和 DPU 就没法共享数据了。于是有了第二层设计：把”什么时候搬”的主动权交给 DPU。

  • 周期性地拉与推：DPU 侧有 puller 和 pusher 两个线程，它们定期通过 DMA 去查看主机侧环形缓冲的元数据（写指针和读指针）。有数据就搬走，有空间就送回来——节奏由 DPU 定，不由主机定。
  • 惰性同步：主机是 x86、DPU 是 Arm，两者内存模型不同，又隔着 PCIe 和 DMA 共享环形缓冲，一致性问题很棘手。论文没有用 DPU 自带的同步原语（嫌它慢、也不想绑死具体厂商），而是用一对序号计数器做惰性同步——思路借自 seqlock 和 FaRM：改元数据之前先抬计数器，改完之后再抬一次，对方看到两次读数不一致就丢弃这次拷来的元数据。用一对计数器而不是一个（也没有用”奇偶判断”那套）+ 避免用 CPU 拷贝，是为了少发几条昂贵的 DMA 命令。
  • 缓冲之间直接搬：数据项从主机的发送缓冲直接 DMA 到 DPU 的发送缓冲，中间不经过 DPU 的 CPU 内存拷贝。
  • 节点级的缓冲管理：一对节点、每个方向只有一个环形缓冲、一条连接，不管上层软件开了多少条连接。这是个安全决定而不是性能决定——如果允许上层动态改变连接数，主机就能靠”改连接数”影响传输节奏，信道又回来了。

📡 对付运营商：把网线流量变成节拍器

第二条战线才是真正的正面战场：云网络运营商能直接看到这根线上的每一个包。

思路仍然朴素，但执行起来很讲究。DPU 上的 regularizer 按固定时间间隔往对端 DPU 发固定大小的数据：有真数据就发数据，没有就发假数据（对端收到后直接丢弃）。对端收到的要么是真数据项，要么是假数据项，而网络上的观察者分不出哪个是哪个——因为两者同样大小、同样加密。

支撑这套整形的还有几个实现上的取舍：

  • 用 RDMA 单向操作：发送方用 RDMA Read 读对端接收缓冲的元数据（为了惰性同步），用 RDMA Write 写数据，并把元数据搭车捎过去（WRITE_WITH_IMM），省掉一次独立的 RDMA 操作。整个 DPU 之间的传输模式因此变成”小的 Read + 大的 Write”，两种都是固定尺寸。
  • 连接要持久：节点之间的连接在部署时就建好，一直用到系统结束。不按应用的需求建连接，因为按需建连接本身就构成一个信道（连接数会随上层行为变化）。
  • 加密在 DPU 上做：主机不可信，所以加密不能交给它。IOValve 假设网络是几十到上百 Gbit/s，加密必须硬件加速，于是选了 RoCEv2（RDMA 走 UDP），用 IPSec 的硬件加速来保护这些 UDP 包——因为它比 InfiniBand 自带的加密方案更容易拿到。

📊 实测：给这套分工结一次账

🧪 先量主机这条路断没断

论文把”leakage-free”这个断言，落成了一个对照实验。逻辑是：主机与 DPU 之间共享的硬件只有两处，主机内存和 DPU 的 PCIe switch，那么在单租户加流量过滤的前提下，恶意代码只剩”调制合法流量”这一条路。于是他们直接去量这条路上的延迟。

做法是拿 qperf 测 64 字节（一个缓存行）的 RDMA Write 往返延迟，一边跑压满 DRAM 带宽的基准程序制造拥塞，看延迟变不变：

数据放在哪 无拥塞 有拥塞 结果
主机内存（常规做法） 6.06 µs 8.75 µs 变慢 44%——包间延迟差异清晰可辨，信道成立
DPU 内存（IOValve） 7.04 µs 7.09 µs 变慢 0.7%——拥塞传不过来

这张表就是全文最核心的证据：不是”我们加密得好”，而是”恶意方根本没有可调节的那个变量”。注意第二行的绝对值本来就更慢（7.04 对 6.06 µs），这是把缓冲搬到 DPU 的固定代价；关键在于它对拥塞不敏感。

🐢 再看代价

在应用之前，先看纯网络层面的开销（这部分是 IOValve 最难看的地方）：

  • 延迟比 stock NCCL 高 77.4%～2.8 倍；
  • 吞吐比 stock NCCL 低 16.8%～39.1%。

到了真实负载，因为节点内计算本身很重，网络开销被摊薄了：

应用 配置 IOValve 的代价
LLM 微调 Llama 3 8B / 70B，QLoRA（4-bit NF4）+ PyTorch FSDP，FP16，No Robots 数据集 训练时间增加 2.1%～4.1%
LLM 批量推理 Llama 3 8B，两张 GPU 张量并行，不用采样、不用 KV cache，每题生成 50 token token 生成吞吐下降 0.2%～8.5%（摘要口径 1.4%）
分子动力学模拟 深度学习模型训练 时间增加 3.4%～5.1%

一个值得注意的规律：模型越大、训练指令越多，IOValve 的相对开销越小——因为计算占比更高，网络被进一步摊薄。另外，这三个应用一行代码都没改，IOValve 是在 NCCL 的网络插件层接进去的。

⚠️ 边界：哪些角色被排除，哪一招有天花板

这类”我做到了 X”的论文，最该读的是它自己在哪让步。IOValve 的边界相当清楚，而且第一条正好和 LLM 对话场景冲突：

① 对 chatbot 这类动态、延迟敏感的场景不合适。 论文在 Limitations 里主动交代了这一点，而且点得很准：

技术上我们可以在用户本地机器和 DPU 之间也做整形（就像 DPU 之间那样），来安全地交换 prompt 与 response，从而缓解 token-length side-channel attack。但由于 prompt 与 response 的长度基本不可预测，我们就得把传输单元放大很多，网络开销变得不可忽略。我们把它留给未来工作。

这段话的分量比它看起来重：它等于承认了“长度本身就是一条信道”，而且恒定整形这套办法在”长度高度可变”的场景下会被开销压垮。这也解释了为什么 IOValve 挑的战场是多机训练——集合通信（AllReduce / AllGather）的流量本来就接近匀速，整形几乎不额外花钱。

② PCIe 只被当作”要防拥塞”的地方。 它对主机和 DPU 之间的 PCIe 链路做的所有限制，目的都是”不让主机制造拥塞”。至于这条链路上传的内容按什么粒度区分对待、哪些包加密哪些不加密——这个问题它不碰，因为它的机密性论证根本不落在 PCIe 上，而是落在”主机里的数据由用户自己的代码处理”这个前提上。

③ 威胁模型把物理攻击排除在外。 论文的假设是：数据所有者信任云厂商的硬件与物理安全，信任 IOValve 自己的固件，只把云厂商的软件、员工和外部黑客当作对手。所以主板配置被改、机箱被打开、在链路上插探针，这些都不在它的防御范围内——也就是角色表里那两类被排除的角色。

④ 只保机密性，不保可用性与完整性。 论文说得很直接：被攻陷的 adapter 故意破坏元数据同步，只会造成完整性和可用性问题，那是本文范围之外的。

⑤ 部署门槛：需要带 DPU 的裸金属实例，不适用于虚拟机（CVM 上跑不了）；需要主机上有 NCCL 支持和一个类似用户态网卡驱动的网络插件。

🔭 换个位置读：它在”独立可编程设备”这条线上的位置

把这篇放回更大的图里，它其实在回答一个比”怎么防隐蔽信道”更一般的问题：当你想在主机之外设一个可信的执法点时，那个执法点应该放在哪、拿什么当判断依据？

IOValve 给的答案是把执法点放在一块独立的 PCIe 设备上（DPU），按数据流身份做判断——加密用的是”哪些流量属于这个用户”（密钥绑定），整形用的是”按固定节拍发”，都不看包的内容与地址。它要的保证是”外面什么都看不出来”，代价是网络层面的延迟与吞吐明显变差、对可变长度的场景不适用。

对做链路观测的人来说，这篇还有两个可以直接带走的东西：

  • “独立设备上的执法点”这个构造已经是主流了。 一篇 CCS’25 论文把它的整个保密性论证押在这上面，说明”主机不可信 + 旁边挂一块可信可编程设备”不再是奇思妙想，而是设计空间里的一等公民。
  • 它给”看不到”立了一个可量化的判据。 那 44% 对 0.7% 的对照，是一个可以直接照抄的实验范式：要论证某条信道不通，就找到那个”可以被恶意方调节的变量”,量出它在有对抗和无对抗下的差异。

✅ 总结

把沙箱边界从处理器核挪到网线上，换来的不是更强的加密，而是”没有可调节的变量”。 IOValve 让 DPU 成为主机唯一的网卡、让通信缓冲住在 DPU 内存里、让出网流量按固定节拍走固定大小的包——于是沙箱里恶意代码唯一可能的出口（调制网络流量）被掐掉了，而它自己量出来的证据是：数据放主机内存时，拥塞会把 RDMA 延迟推高 44%；数据放 DPU 内存时只动 0.7%。

三个可以带走的要点：

  1. 它的核心不是密码学，是”把恶意方能拨动的那个旋钮拆掉”。 加密只保证”看不懂”，加密加得再好也拦不住”传得快一点还是慢一点”，整形拦的才是这个。
  2. 它的强项和软肋是同一件事：恒定整形。 流量本来就匀速（多机训练的集合通信）时几乎免费；流量高度可变（LLM 对话的 prompt 与 response 长度）时，要么开销爆炸要么放弃——论文自己承认这条，并把它列为未来工作，顺带点出了 token 长度本身就是一条侧信道。
  3. 它的威胁模型有一道清晰的门：“物理接触者被排除在外”。 而这条线上其他工作的结论恰恰相反——PCIeHardwareMitM 与 Hermes 都要求物理接触，它们证明的正是”能碰到硬件就什么都拿得到”。这两类工作的结论放在一起看才有意思：一个说”我堵住了一切”，另一个说”只要让我碰一下线就够了”。

🔗 这条路线上还有哪些工作

工作 来源 站在哪一侧 入手点
Hermes Attack USENIX Security 2021 攻击 明文 PCIe 流量，lossless 重建 DNN
PCIeHardwareMitM Microprocessors & Microsystems 2020 攻击 把 FPGA 插进链路中间，读包改包
PCIeMonitor CSR 2025 防御 在 PCIe 端点里做硬件旁路，匹配指令模式查挖矿
IOTLB-SC AsiaCCS 2023 攻击 共享 IOMMU 的设备测 DMA 时延
DevIOus S&P 2023 攻击 两个 DMA 设备争用 IOTLB
IOValve（本文） CCS 2025 防御 在 DPU 上做 I/O 沙箱，把流量整形成恒定节拍

（本文为 CCS ’25 论文 IOValve: Leakage-Free I/O Sandbox for Large-Scale Untrusted Data Processing 的精读笔记，正文表格内的数据取自论文原文。）