MOLE: Breaking GPU TEE with GPU-Embedded MCU

会议：CCS ‘25

作者：Hongyi Lu; Yunjie Deng; Sukarno Mertoguno; Shuai Wang; Fengwei Zhang

背景介绍

可信执行环境（TEE）向来是安全的代名词，其利用各类硬件特性对关键数据进行保护。在各种可信执行环境的实现中，有一大类别专攻于针对 GPU 的保护。通过对 GPU Buffer 等关键数据进行加密或者内存权限保护，阻止高权限攻击者（如 OS 等）对 GPU 数据的窃取和篡改。

本文首次提出了一个针对 Arm GPU TEE 的攻击手段，通过对 Arm GPU 上的 MCU 加载恶意固件，并利用各类安全特性（例如 TrustZone）无法区分 GPU 与 GPU MCU 的特点，实现经由 MCU 的针对 GPU TEE 的数据窃取与篡改。

Arm GPU MCU

为了减轻 CPU 调度 GPU 任务的负担，现代 GPU 通常都会引入一颗内嵌处理器来负责调度 GPU 资源与任务。Arm 也不免俗，如上图所示，在用户 App. 将任务提交给内核态驱动后，内核态驱动并不进行调度，而是直接向 GPU 的 MCU 发起中断通知其进行任务处理，然后 MCU 再将任务调度给 GPU 内部的计算单元和渲染单元。

然而，这颗 MCU 作为一颗全功能 MCU，本身可以执行任意指令并且在内存总线上与 GPU 被视为同一个设备，那么就给 GPU TEE 带来了新的安全挑战。例如如何在确保不影响正常 GPU 任务的情况下，确保 MCU 无法危害到 TEE 内部的程序。也正是这一新引入的 MCU 使得之前的 GPU TEE 防御形同虚设。

Arm 安全特性

由于目前 Arm 上并没有第一方的 GPU TEE，大部分学术研究集中在如何利用 Arm 的安全特性（例如 TrustZone）提供一个足够安全的 GPU 执行环境。

如上图所示，Arm 目前提供的硬件安全特性大致有，Arm CCA，Stage-2 虚拟化，TrustZone安全世界隔离，SMMU 等。

然而，这些硬件由于设计的原因，不可避免的将 GPU MCU 与 GPU 一般的计算单元视为同一个硬件，这就导致所有这些安全特性都无法提供 GPU MCU 与 GPU 本身计算单元之间的隔离。

GPU TEEs on Arm

GPU TEEs 通常分为两种，分别为虚拟机式和垫片式，如下图所示，虚拟机式将整个 GPU 软件栈统一打包进虚拟机中，以提供最好的兼容性（但同时增大了 TCB 与攻击面），而垫片式则通过将非安全组件（如电源管理等）划分到 TCB 外部，以减小攻击面。

然而，正是这一设计，导致垫片式 GPU TEEs 易受到来自恶意 MCU 的攻击。尽管垫片式 GPU TEE 为了确保数据不被 OS 窃取，在经过 OS 管理的驱动代码时，会将相关的内存进行加密，直到 GPU 进行计算时再解密（GPU 无法处理密文，因为并不是同态加密）。MCU 作为 GPU 的一部分，直接收到的就是明文，又由于已有的安全机制都无法有效的隔离开 MCU 和 GPU 计算单元，因此 MCU 可以直接窃取或者篡改明文数据

垫片式 GPU TEEs 为了减小 TCB 的大小，将大量的安全无关代码委托给了非安全世界，例如 GPU 初始化，电源管理等，而只关注安全相关代码，例如内存管理，调度，中断管理等。下表总结了各个 GPU TEE 在安全任务与非安全任务执行时所保护的组件范围。

可以看到，所有的 GPU TEEs 都不在GPU 管理程序运行时进行保护，而只在安全任务执行时才进行保护。这样的设计也是有道理的，因为 GPU 管理程序通常只涉及到 GPU 的初始化等配置任务，其不会影响到安全任务的执行，也不在时间上与安全任务重叠。

然而，MCU 的出现打破了这一假设，通过对 MCU 注入恶意组件的方式，我们的工作实现了使恶意代码在时间上与安全任务共同执行，并且通过 MCU 对安全任务的内存进行攻击。

MCU 威胁分析

我们通过逆向工程，顺利找到了 GPU MCU 的架构以及基础信息，如下图所示。

为了达成攻击目标，我们需要做到以下几件事

1. 固件篡改，需要验证 GPU 内部以及 GPU TEE 本身没有任何验证固件的措施，由于 MCU 的代码是闭源的，第三方的 GPU TEE 不可能对其进行检验，而 Arm 官方也没有实现任何的验证机制，因此我们很轻松的就实现了对固件的篡改

2. 绕过内存保护，MCU 内部内置了一个 MPU 保护单元以及一个 MMU，前者可以由固件内部代码直接关闭，而后者则需要恶意的 OS （TEE 的威胁模型假设 OS 级别的恶意攻击者）配合将一块内存嵌入到 MCU 的页表中，以实现对任意系统内存的映射。最关键的是，我们同样验证了 TrustZone 与 Stage-2 MMU 是无法区分 GPU 与 GPU MCU 的。

3. 恶意代码触发，MCU 遵循一种事件驱动的执行方式，我们通过修改其在GPU 任务提交与GPU任务完成的两个中断处理代码使其绕开 GPU TEE 本身的加解密流程

MOLE 攻击

如上图所示，MOLE 攻击分为以下几个步骤。

1. GPU 初始化时，恶意 OS 加载一个被篡改的固件代码到 GPU MCU 上，其设定为在 GPU 提交和完成任务时会更改/窃取 GPU 的任务数据。
2. GPU 加密数据，经过 OS 的不可信 GPU 驱动，再由 TEE 通过 CCA 或者 Stage-2 保护 GPU 数据，最后再经过解密（这一块 MOLE 不做任何事）
3. 当 GPU 任务的数据最终以受保护的明文抵达 GPU 时，GPU MCU 则可以任意修改其数据或者将数据转发到与恶意 OS 的共享内存之中。

实验结果

YOLOv4 检测结果替换

In-GPU AES 密钥提取

总结

MOLE 首次提出了一种新颖的针对 GPU TEE 的工具，我们希望以此来引起业界与安全学术界对于这类 MCU 的注意。在未来的 TEE 设计中，充分考虑到这类闭源组件带来的安全风险与挑战。