AI Security

外观

AI 基础设施与 MLOps 安全 · A4.3 推理服务与模型服务器更新 2026-09-02约 5 分钟证据：中等 来源：arXiv:2608.29745

JITterFlip：JIT 编译推理控制面的故障注入攻击 ​

摘要 ​

JITterFlip 将比特翻转目标从模型权重和计算内核转向 CPU 侧即时编译（Just-in-Time, JIT）推理控制面。该控制面决定复用哪个编译制品以及如何向 GPU 提交工作；单个分支指令被翻转后，可让服务输出乱码，也可在输出保持完全一致时把请求导向昂贵路径，从而绕过只检查输出正确性的防护。

作者在四个文本与多模态工作负载上报告，模拟故障造成 15.45 倍至 (2.48\times10^6) 倍困惑度放大，或 2.03—181.90 倍时延放大；端到端 Rowhammer 实验中，单个 CPU 常驻分支位翻转造成最高 (7.23\times10^6) 倍困惑度放大，或在输出完全相同的情况下造成 97.38—124.97 倍时延放大。

核心创新与差异 ​

原研究贡献是识别 JIT Serving 中“编译制品选择”和“GPU 工作提交”两类控制决策，并用决策导向分析从 181 个文件、13.91 万行源代码缩小到 34 个文件、3.47 万行相关代码，再对 36,861 个条件分支分别按两类攻击目标排序。

本站分析认为，最先失效的是推理服务宿主控制代码的内存完整性。它不同于修改模型权重的后门，也不同于只泄露信息的加速器侧信道：故障位于 CPU，但影响跨越 CPU—GPU 边界传播到推理执行与资源调度。

威胁模型与攻击链 ​

攻击者是与目标服务共置的低权限租户，能够在存在可利用 DRAM 故障条件的主机上实施 Rowhammer，并掌握目标运行时版本。攻击不要求写入 GPU 显存。

  1. 识别 JIT 编译栈中与制品选择或 GPU 提交相关的分支。
  2. 选择翻转后仍保持进程存活的控制流目标。
  3. 通过 CPU DRAM 故障翻转目标分支的一位。
  4. 控制面选择错误制品、跳过工作或转入较慢但语义等价的执行路径。
  5. 服务产生明显错误输出，或在输出正确时消耗异常时延。

攻击方法与复现材料 ​

以下是本站依据公开机制重构的去武器化测试状态机，不包含 Rowhammer 地址定位、内存映射或锤击参数：

text
LOCAL_ONLY = true
baseline = run_jit_fixture(branch_mode="normal", max_time_ms=1000)
faulted  = run_jit_fixture(branch_mode="simulated_flip", max_time_ms=1000)
record(output_hash(baseline), output_hash(faulted))
record(latency(baseline), latency(faulted), selected_artifact(faulted))
assert no_physical_fault_injection and no_third_party_target

该夹具对应攻击链第 3—5 步，只验证控制分支故障是否改变制品选择、输出或时延。检测信号包括编译制品 ID 异常、GPU 提交计数变化、输出哈希变化，以及“输出相同但时延激增”。

实验设计与实际过程 ​

以下均为作者实验，本站未独立复现。实现基于 PyTorch 2.9.1 的 torch.compile—Inductor—Triton 栈和 CUDA Graph。作者以 Qwen3-8B、DeepSeek-R1-Distill-Qwen-7B、Gemma-3-4B 和 Qwen2.5-VL-7B 覆盖 WikiText-2 与 ScienceQA 工作负载：文本输出破坏使用 WikiText-2 前 512 个 Token 和固定 32 Token 生成，多模态输出破坏使用 3 道固定 ScienceQA 题；时延测试对每个模型使用 1 个固定请求并重复测量。

候选搜索对输出破坏和时延放大各测试排名前 20 的分支；随机基线在相同 20 次预算下使用 3 个独立种子。端到端阶段在单台非 ECC DDR4 主机上对每个模型—工作负载设置诱发一个 CPU 常驻分支位翻转，再观察 GPU 推理结果，以证明影响不是纯软件故障模拟。时延取固定请求多次运行的平均值，但论文没有披露重复次数。论文也没有证明所有 JIT 版本、编译后端或云主机都满足可利用的物理条件。

关键结果与实际影响 ​

  • 两份各含 20 个候选的排序列表中，作者分别找到 5/20 个输出破坏分支和 10/20 个时延放大分支；顺序遍历基线与 3 次独立随机抽样均为 0/20。
  • 模拟故障的输出破坏条件报告 15.45 倍至 (2.48\times10^6) 倍困惑度比，正确输出型时延放大为 2.03—181.90 倍。
  • 端到端 Rowhammer 在四个固定模型—工作负载设置上各以一个分支位翻转产生 287.3 倍至 (7.23\times10^6) 倍困惑度放大；另一个分支位翻转在四个固定请求上造成 97.38—124.97 倍时延放大，返回 Token 序列与干净基线一致。
  • FaR 与 LM-Fix 关注模型状态或输出语义，未覆盖 JIT 控制面，作者报告攻击效果仍保留。

现实影响包括输出完整性破坏、单请求资源占用和共享 Serving Runtime 的可用性下降。倍数来自指定软件栈和硬件实验，不代表生产服务的普遍放大率。

防护措施与验证方法 ​

  • 将 JIT 控制代码、编译缓存索引和 GPU 提交路径纳入代码完整性与内存错误检测。
  • 对关键选择分支使用控制流完整性、冗余判定或硬件纠错保护；不要只保护权重页。
  • 为编译制品建立摘要、形状 Guard 与请求绑定，记录实际选中制品和回退路径。
  • 同时监控输出异常与“相同输出、异常时延”，并按租户设置执行时间和 GPU 工作预算。
  • 在发布测试中注入受控软件故障，覆盖编译缓存命中、重新编译、CUDA Graph 重放和回退路径。

局限与待验证问题 ​

证据来自单篇预印本和作者实验，尚无独立复现。攻击要求共置、可利用的 DRAM 故障、目标版本知识和可靠位翻转；云平台内存加密、纠错、页面隔离与刷新策略会改变可行性。研究覆盖四个模型和特定 PyTorch 编译栈，不能外推到所有 JIT 或非 JIT Serving Runtime。

参考链接 ​