一、论文信息与研究背景

1.1 论文信息

  • 标题：GhostAccess: Attacking the GPU on the Multi-tenant Cloud via CPU LLC under Unified Memory
  • 作者：Zihao Dan, Shinan Liu, Shuwen Deng, Yanan Guo, Yinqian Zhang, Dongsheng Wang, Yun Chen
  • 机构：香港科技大学（广州）
  • 会议：MICRO 2026（第 59 届 IEEE/ACM 国际微体系结构会议，2026 年 10 月，希腊雅典）
  • 披露状态：已负责任披露给 NVIDIA 安全团队并得到确认

1.2 研究背景

公有云 GPU 实例已成为大模型训练与推理的基础设施。云厂商普遍以 NVIDIA 的 MIG（Multi-Instance GPU）、vGPU、MPS 等机制向多个租户共享同一颗物理 GPU，并承诺计算、缓存、内存控制器等资源在租户间物理隔离。GhostAccess 的核心贡献在于揭示了一个被长期忽视的耦合路径：GPU 通过 CUDA 统一内存（Unified Memory, UM）向系统内存写入数据时，数据会被强制加载到 CPU 的末级缓存（LLC）中，而下级缓存对应行被失效。这一行为类似于 Intel DDIO（Data Direct I/O），但从未在 NVIDIA 官方文档中被描述。

由于 CPU LLC 是跨租户共享资源，攻击者只要在 CPU 侧租户上运行 Prime+Probe，就能观测到 GPU 侧租户通过 UM 写操作留下的 LLC 痕迹，从而在两个物理隔离的租户之间建立侧信道与隐蔽信道。这是首个攻击者完全不需要 GPU 访问权限、且 MIG 隔离对其近乎无效的跨租户 GPU 攻击。

二、核心发现：UVM 一致性行为逆向

2.1 统一虚拟内存（UVM）机制

CUDA Unified Memory（统一内存）为 CPU 与 GPU 提供统一的虚拟地址空间，由驱动与硬件协作完成页迁移与一致性维护。开发者通过 cudaMallocManaged 分配内存，并通过 cudaMemAdvise 系列接口向驱动提供迁移提示。其中 cudaMemAdviseSetPreferredLocation 用于将某段内存的"首选位置"固定到指定设备。

当 GPU 通过此类 UM 映射向系统内存（host memory）写入数据时，驱动与一致性协议会触发一条特殊的数据路径，这条路径的缓存行为是 GhostAccess 的攻击根基。

2.2 关键技术发现

GhostAccess 首次系统性逆向了 UVM 中未被文档记录的、针对 CPU 侧缓存的一致性行为：

  • GPU 写操作：当 GPU 通过 cudaMemAdviseSetPreferredLocation 建立映射并向系统内存写入数据时，数据被直接加载到 CPU 的 LLC 中，且下级缓存（L1/L2）对应行被失效（invalidate）。这一行为类似 Intel DDIO，使数据驻留在 LLC 以便 CPU 快速访问。
  • GPU 读操作：不改变 CPU 缓存状态，不会在 LLC 留下痕迹。
  • 时序特征：GPU 写操作发生后，CPU 端访问该地址的延迟稳定降至 LLC 命中级别（约 160 cycles）；若 GPU 未写过，CPU 访问需穿透到下级缓存或内存（约 300+ cycles）。
  • 平台验证：在 5 种 CPU+GPU 组合上验证（覆盖阿里云、AWS 等公有云环境），行为一致。

下图刻画了 GPU 写操作引发的双向缓存状态变化：

            GPU 侧 (租户 A)                     CPU 侧 (共享 LLC)
   +-------------------------+        +----------------------------------+
   | cudaMemAdviseSetPrefLoc  |        |   LLC (末级缓存, 跨租户共享)       |
   |   建立系统内存 UM 映射     |        |  +-----+ +-----+ +-----+ +-----+ |
   +-------------------------+        |  |set 0| |set 1| |set 2| |...  | |
                |                     |  +-----+ +-----+ +-----+ +-----+ |
                v                     |      ^            ^                |
   +-------------------------+        |      |            |                |
   |   GPU 写系统内存 (UM)    |--------+------+------------+                |
   |   数据强制加载到 CPU LLC |        |  数据驻留 LLC (命中 ~160 cyc)      |
   +-------------------------+        |  下级 L1/L2 对应行被失效           |
                                     +----------------------------------+
            GPU 读操作 --> 不改变 CPU 缓存状态 (无痕迹)

2.3 攻击可行性根源

这一发现的安全含义在于：GPU 厂商在实现跨设备内存优化时，隐式地让一个本应"属于 GPU"的写操作在 CPU 的共享 LLC 上留下了可观测的状态。而 LLC 恰恰是跨租户共享且经典侧信道攻击（Prime+Probe）的主战场。于是，一个物理上分配给租户 A 的 GPU，通过 UM 写操作，在租户 B（CPU 侧）可见的 LLC 上"投下阴影"——这正是 GhostAccess 命名的由来。

三、GPU 多租户共享隔离机制

在分析攻击之前，需要先理解 GPU 多租户共享的三种主流隔离机制，以及它们各自的隔离边界。

3.1 MIG（Multi-Instance GPU）

MIG 是 NVIDIA 在 Ampere 架构（A100）引入的硬件级 GPU 分区技术，将一颗物理 GPU 空间分区为多个 GPU 实例（GI）：

  • 每个 GI 拥有专用计算资源（SMs/GPCs）
  • 每个 GI 拥有专用 L2 缓存切片
  • 每个 GI 拥有专用内存控制器和 DRAM 通道
  • NVIDIA 声称 MIG"确保一个 client 不能影响其他 client 的工作"
  • A100 最多 7 个 GI，H100 最多 7 个 GI

MIG 的设计目标是提供强隔离的"GPU 切片"，使每个租户在计算、L2、显存层面互不可见。

3.2 vGPU

vGPU 采用内存分区共享 GPU、计算资源时间片共享的方式。现代部署中通常将 vGPU 与 MIG 结合：将专用 GI 分配给每个 VM，以获得更强的隔离。

3.3 MPS（Multi-Process Service）

MPS 允许多个 CUDA kernel 在同一 GPU 上并行执行，提升利用率。但 MPS 不提供地址空间隔离或错误隔离，不可用于多租户互不信任场景。

下图刻画了 GPU 多租户共享架构与各机制的隔离边界：

   +================================================================+
   |                    物理 GPU (A100/H100)                        |
   |                                                                |
   |   +-----------------+   +-----------------+   +-------------+  |
   |   |  GI-0 (租户A)  |   |  GI-1 (租户B)  |   |  GI-2 ...   |  |
   |   | 专用 SMs/GPCs  |   | 专用 SMs/GPCs  |   |             |  |
   |   | 专用 L2 切片   |   | 专用 L2 切片   |   |             |  |
   |   | 专用 DRAM 通道 |   | 专用 DRAM 通道 |   |             |  |
   |   +-----------------+   +-----------------+   +-------------+  |
   |          MIG 硬件分区边界 (计算/L2/DRAM 隔离)                   |
   |                                                                |
   |   <-- MPS: kernel 并行, 无地址/错误隔离 (不可用于互不信任) -->    |
   |   <-- vGPU: 内存分区+时间片; +MIG 则分配专用 GI 给 VM -->        |
   +====================+===========================================+
                        |
                        |  PCIe / C2C Link
                        v
   +================================================================+
   |              CPU 侧 (系统内存 + LLC, 跨租户共享)                |
   |   +-----------------+   +-----------------+                     |
   |   |  CPU 租户 (A)  |   |  CPU 租户 (B)  |  <-- GhostAccess    |
   |   |  共享 LLC      |<==|  共享 LLC      |      攻击者在此      |
   |   +-----------------+   +-----------------+                     |
   |          LLC 是跨租户共享资源, MIG 不隔离 LLC                  |
   +================================================================+

关键观察：MIG 隔离了 GPU 内部的计算、L2 与 DRAM，却无法隔离 CPU 侧的 LLC。一旦 GPU 的 UM 写操作把数据"溅射"到 CPU LLC，MIG 的硬件分区边界就被绕过了。

四、GhostAccess 攻击原理与信息流

4.1 信息流架构

GhostAccess 的攻击者完全在 CPU 侧操作，不需要任何 GPU 访问权限。攻击的信息流如下：

   受害租户 (GPU)                CPU 系统内存              CPU LLC 缓存状态
   +-------------+               +-------------+          +-----------------+
   |  UM 映射写   | --写入数据--> | 系统内存页  | --加载-->| LLC 缓存集变化  |
   |  (Trojan)   |               | (host mem)  |          | (驱逐/驻留)     |
   +-------------+               +-------------+          +-----------------+
                                                                  ^
                                                                  | 观测
                                                                  v
                                                    +-------------------------+
                                                    | 攻击者租户 (CPU)        |
                                                    | Prime+Probe LLC 缓存集  |
                                                    | (无需 GPU 权限)         |
                                                    +-------------------------+

攻击者利用 Prime+Probe 监控特定 LLC 缓存集的驱逐情况：若 GPU 侧通过 UM 写入了映射到该缓存集的地址，攻击者 Prime 后该地址的数据驻留 LLC，Probe 时表现为命中（低延迟）；若 GPU 未写入，攻击者 Prime 的数据可能被驱逐或地址未驻留，Probe 表现为未命中（高延迟）。

4.2 侧信道攻击原语：Prime+Yield+Probe

由于受害者在 GPU 上执行，攻击者在 CPU 上无法直接控制时序同步。GhostAccess 设计了 Prime+Yield+Probe 三阶段原语：

  1. Prime：攻击者先用 eviction set 填充目标 LLC 缓存集，驱逐其他数据。
  2. Yield：攻击者调用 sched_yield() 让出 CPU 核心，等待受害 GPU 执行 UM 加速任务（此时 GPU 写操作改变 LLC 状态）。
  3. Probe：攻击者重新探测缓存集，统计命中/未命中，收集执行轨迹。
   时间轴 ------------------------------------------------------------>

   攻击者(CPU):  [Prime 填充set]--[sched_yield 让出]----[Probe 探测统计]
                                        |                    ^
                                        v                    |
   受害者(GPU):                [UM 加速任务执行]                |
                                    |  GPU 写系统内存            |
                                    v  数据加载到 LLC           |
   LLC 状态:    [set 被攻击者填充] --> [set 被GPU写驱逐/驻留] --> [攻击者探测命中模式]
                                                                     |
                                                          解码: 命中(~160cyc)=1
                                                                未命中(~300cyc)=0

4.3 隐蔽信道攻击原语：Trojan-Spy 通信

在隐蔽信道场景中，攻击者同时控制 GPU 侧的 Trojan 与 CPU 侧的 Spy，二者通过 LLC 状态传递信息：

  • Trojan（受害 GPU 上）：通过 UM 映射写内存编码比特 1（不写代表 0）。GPU 写操作会把数据加载到 CPU LLC。
  • Spy（攻击者 CPU 端）：通过 Prime+Probe 监控 LLC 缓存集驱逐解码。LLC 命中（约 160 cycles）表示 GPU 写过（比特 1），未命中（约 300+ cycles）表示 GPU 未写（比特 0）。

五、攻击原语代码示例

下面给出 GhostAccess 攻击的概念性伪代码，用于说明攻击原理。

# GhostAccess 攻击概念伪代码
import ctypes
import time
import sched

# 攻击者（CPU侧租户）—— Prime+Yield+Probe
class GhostAccessAttacker:
    def __init__(self, target_cache_set):
        self.cache_set = target_cache_set

    def prime(self):
        """填充目标缓存集，驱逐其他数据"""
        # 通过eviction set填充特定LLC缓存集
        for addr in self.eviction_set:
            self.read_cached(addr)

    def yield_and_wait(self, duration_ms):
        """让出CPU核心，等待GPU执行UM操作"""
        time.sleep(duration_ms / 1000.0)

    def probe(self):
        """探测缓存集，统计命中/未命中"""
        timings = []
        for addr in self.eviction_set:
            t0 = time.perf_counter()
            self.read_cached(addr)
            t1 = time.perf_counter()
            timings.append(t1 - t0)
        return timings

    def decode(self, timings, threshold):
        """根据访问时间解码比特"""
        # LLC命中(~160 cycles) = '1'(GPU写过)
        # LLC未命中(~300+ cycles) = '0'(GPU未写)
        return 1 if sum(timings) / len(timings) < threshold else 0

# 受害者（GPU侧租户）—— Trojan
class GhostAccessTrojan:
    def __init__(self, um_mapped_addr):
        self.addr = um_mapped_addr  # UM映射的系统内存地址

    def send_bit(self, bit):
        """通过GPU UM写操作发送比特"""
        if bit == 1:
            # GPU通过UM映射写内存 -> 数据加载到CPU LLC
            self.gpu_write(self.addr, payload_data)
        # bit == 0时不写，不改变CPU LLC状态

    def send_byte(self, byte_val):
        """并发发送8比特（利用GPU并行性）"""
        # 启动8个GPU线程，同时向映射到不同缓存集的地址写入
        kernel = self.build_parallel_kernel(byte_val)
        kernel.launch(num_threads=8)

需要注意，上述伪代码中的 read_cached、gpu_write、build_parallel_kernel 等均为概念占位。实际实现中，攻击者需要构造 LLC eviction set（通过经典的缓存冲突地址推导）、并通过 CUDA UM API 完成 GPU 侧写操作。decode 的阈值需根据具体平台的 LLC 命中/未命中延迟分布校准。

六、并发传输算法

6.1 并行比特传输

GhostAccess 的隐蔽信道性能得益于 GPU 的天然并行性。单个 GPU Kernel 可启动多线程，同时向映射到不同 LLC 缓存集的地址写入，从而在单轮时序内并行传输多个比特：

  • 单个 GPU Kernel 启动 8 个线程，同时向 8 个不同 LLC 缓存集地址写入 → 单轮传输 8 比特（一个字节）
  • 16 个 CPU 线程配合 GPU 并发传输，最终达到 1.02 Mbps 信道容量

6.2 并发传输流程

   GPU Kernel (单轮) :
   +--- thread 0 --> UM写 addr[0] --> LLC set 0  (比特0)
   +--- thread 1 --> UM写 addr[1] --> LLC set 1  (比特1)
   +--- thread 2 --> UM写 addr[2] --> LLC set 2  (比特2)
       ...
   +--- thread 7 --> UM写 addr[7] --> LLC set 7  (比特7)
                    |
                    v
   单轮时序内并行传输 8 比特 (1 byte)

   CPU 侧 (16 线程并发):
   +--- CPU thread 0..15 --> 分别 Prime+Probe 不同 set, 配合 GPU 并发
                    |
                    v
   汇总: 1.02 Mbps 隐蔽信道容量

这种设计巧妙地把 GPU 的大规模线程并行性"翻译"为 LLC 缓存集层面的并行比特通道，是 GhostAccess 达到高带宽的关键。

七、攻击性能评估

GhostAccess 在多种攻击场景下均表现出色：

攻击场景 性能指标
隐蔽信道 1.02 Mbps，错误率仅 0.3%
MIG 隔离有效性 开启 MIG 后信道容量仅降低 4.7%
ML 应用指纹识别 6 种 ML 应用，准确率 99.6%
K-means 参数提取 8 种配置，准确率 99.8%
CNN 架构窃取 8 种卷积核大小，准确率 99.6%
LLM 指纹识别 模型架构和大小，准确率 99.6%

7.1 隐蔽信道性能

隐蔽信道达到 1.02 Mbps、错误率仅 0.3%，比此前最先进的跨租户隐蔽信道快 12.7 倍。这一带宽足以在短时间内传输密钥、模型参数等敏感数据。

7.2 MIG 无效性

开启 MIG 后，信道容量仅降低 4.7%。这是因为 GhostAccess 的信号载体是 CPU LLC，而 MIG 仅隔离 GPU 内部资源，对 CPU LLC 毫无影响。这是 GhostAccess 区别于此前所有 GPU 侧信道攻击的根本特性——攻击者不需要任何 GPU 访问权限。

7.3 侧信道应用场景

在侧信道场景下，攻击者可对受害 GPU 上的工作负载进行指纹识别与参数窃取：

  • ML 应用指纹：通过 Prime+Yield+Probe 收集受害 GPU 上 ML 任务的执行轨迹，识别 6 种 ML 应用，准确率 99.6%。
  • K-means 参数提取：从聚类参数中恢复 8 种配置，准确率 99.8%。
  • CNN 架构窃取：窃取 8 种卷积核大小配置，准确率 99.6%，威胁模型知识产权。
  • LLM 指纹：识别大模型架构与大小，准确率 99.6%，可推断竞争对手的模型选型。

八、相关 GPU 侧信道攻击对比

下表对比 GhostAccess 与其他 GPU 侧信道攻击：

攻击 共享资源 需要GPU访问 MIG有效? 信道容量
GhostAccess CPU LLC 否 无效(仅降4.7%) 1.02 Mbps
Behind Bars L2缓存(membars) 是 无效 未报告
Tunnels for Bootlegging L3-TLB 是 无效 31 kbps
MIGraine PCIe/UVM(页错误) 是 无效 未报告
BarraCUDA EM辐射 物理接触 N/A 参数级

8.1 Behind Bars（USENIX Security 2026）

  • 揭示 MIG 的 L2 缓存分区并非完全隔离
  • membars（内存屏障）可跨 MIG 实例传播
  • LD.STRONG.GPU 指令在 membars 存在时变慢
  • 首个跨 MIG 实例的缓存攻击，但仍需 GPU 访问权限

8.2 Tunnels for Bootlegging（CCS 2023）

  • 发现 MIG 不分区最后一级 TLB（L3-TLB）
  • 所有 MIG 实例共享 L3-TLB
  • 故意制造 L3-TLB 争用构建隐蔽信道
  • 传输速度 31 kbps，准确率 99.8%

8.3 MIGraine

  • 利用 UVM 页错误中断产生跨 GI 干扰
  • 页错误缓冲区跨 GI 共享
  • 可指纹识别 LLM 工作负载，准确率 96%

GhostAccess 与上述攻击的根本差异在于：它不需要攻击者拥有任何 GPU 访问权限，攻击面完全在 CPU 侧的 LLC，而 MIG 对 LLC 无能为力，因此 MIG 隔离近乎完全失效。下图对比了各攻击在 MIG 隔离下的有效性：

   MIG 隔离有效性对比 (信道容量衰减):

   GhostAccess          [████████████████████] 仅降 4.7%  --> MIG 无效
   Behind Bars          [MIG 对 L2 membars 无效]         --> MIG 无效 (但需GPU访问)
   Tunnels for Bootleg. [MIG 对 L3-TLB 无效]              --> MIG 无效 (但需GPU访问)
   MIGraine             [MIG 对页错误缓冲区无效]          --> MIG 无效 (但需GPU访问)

   关键差异:
   +-------------------+----------------+-------------------+
   |  攻击者需要GPU?  |  攻击载体      |  MIG 能否阻断?    |
   +-------------------+----------------+-------------------+
   | GhostAccess: 否   |  CPU LLC       |  否 (仅降4.7%)   |
   | 其他攻击:   是   |  GPU内部资源   |  否 (但需GPU权限) |
   +-------------------+----------------+-------------------+

九、防御方案

针对 GhostAccess 揭示的攻击面，论文提出以下防御方向：

  1. 重新审视缓存一致性策略：在跨设备内存映射（如 UM 写操作）时，限制类似 DDIO 的行为，避免 GPU 写操作强制将数据加载到 CPU LLC。可考虑将 GPU 写入的系统内存数据绕过 LLC 或仅驻留在 GPU 专用缓存路径。

  2. CPU 侧缓存集按租户隔离：对 LLC 缓存集实施租户级分区（如基于 Intel CAT/AMD L3 CAT 技术），确保不同租户的 LLC 使用互不重叠，从物理上切断 Prime+Probe 的观测路径。

  3. 切断跨租户 UM 映射路径：在云调度层限制或禁用跨租户场景下的 UM 系统内存映射，或在 hypervisor 层对 UM 写操作引入额外隔离。

  4. L3-TLB 按 GI 分区：针对 Tunnels for Bootlegging 揭示的缺陷，将 L3-TLB 按 MIG 实例分区，消除共享 TLB 带来的侧信道。

  5. membars 隔离：针对 Behind Bars 揭示的缺陷，强化 membars 的跨实例隔离，防止跨 GI 传播。

  6. 页错误处理隔离：针对 MIGraine 揭示的缺陷，将页错误缓冲区按 GI 隔离，避免跨实例干扰。

  7. 不要将 MIG 视为完整隔离方案：这是最重要的防御原则。MIG 仅隔离 GPU 内部资源，无法覆盖 CPU 侧共享资源。安全评估必须将 GPU-CPU 跨设备路径纳入威胁模型。

下图给出防御方案的分层视图：

   防御层级:

   +---------------------------------------------------------------+
   | 1. 一致性策略: 跨设备UM写限制DDIO行为, 不加载到CPU LLC          |
   +---------------------------------------------------------------+
   | 2. LLC分区:    CPU侧缓存集按租户隔离 (Intel/AMD CAT)           |
   +---------------------------------------------------------------+
   | 3. 映射切断:    云调度层限制跨租户UM系统内存映射                 |
   +---------------------------------------------------------------+
   | 4. GPU微架构:  L3-TLB按GI分区 | membars隔离 | 页错误隔离       |
   +---------------------------------------------------------------+
   | 5. 安全模型:    不要将MIG视为完整隔离, 纳入CPU侧共享资源威胁模型 |
   +---------------------------------------------------------------+

十、对机密计算的启示

GhostAccess 对机密计算（Confidential Computing）提出了深刻警示。GPU 厂商在引入统一内存等跨设备优化技术时，往往只关注 GPU 侧的性能与功能，缺乏对 CPU 侧微架构状态变化的全面审视。这导致一个被物理隔离的 GPU 资源，通过共享的 CPU LLC 与其他租户发生"隐性耦合"。

在机密计算场景下，这种隐性耦合尤为危险：

  • TEE 边界被绕过：即使 GPU 工作负载运行在受保护环境（如 NVIDIA Confidential Computing, H100 CC mode），只要其 UM 写操作影响 CPU LLC，CPU 侧的攻击者就能通过侧信道推断工作负载行为，破坏机密性。
  • 隔离幻觉：云厂商与租户普遍信任 MIG 提供的物理隔离，但 GhostAccess 证明，GPU 与 CPU 之间的共享路径（LLC、TLB、页错误缓冲区）构成了 MIG 之外的隐性耦合面，这些路径在多租户场景下必须被显式隔离。
  • 跨设备优化的安全债务：UM 等跨设备优化技术显著提升了性能，但其未被文档记录的缓存副作用构成了潜在的安全债务。未来 GPU 架构设计必须将"跨设备写操作对 CPU 微架构状态的影响"纳入安全审计范围。

更广泛地说，GhostAccess 揭示了一个趋势：随着 GPU 与 CPU 的集成度提升（如 Grace Hopper 的统一内存架构、C2C 互连），GPU-CPU 跨设备路径将成为侧信道攻击的新前线。防御方需要从"GPU 内部隔离"思维转向"GPU-CPU 系统级隔离"思维，将所有跨设备共享资源纳入威胁模型。

免责声明

本文为纯技术分析文章，基于 MICRO 2026 公开论文的技术数据撰写，旨在促进安全研究与防御建设。文中所述攻击方法、概念性伪代码与防御方案仅供学术研究、安全评估与系统加固参考。任何读者不得将本文内容用于未经授权的实际攻击、渗透测试或破坏他人系统。在未获得明确授权的情况下对云环境或他人系统实施侧信道攻击属于违法行为，可能违反相关法律法规与云服务条款。作者与发布方不对任何因不当使用本文信息而造成的后果承担责任。云安全研究与防御建设应在合法授权与负责任披露框架下进行。