StrongBox-为Arm终端设备的GPU构建TEE

1. 研究动机

为了满足急剧增加的计算性能需求，GPU已经被广泛部署于服务器端和边缘端设备中，用于处理包括3D游戏、视频处理和压缩、VR以及神经网络训练和推理等高性能计算应用。然而，由于GPU完全受控于操作系统，其计算的安全性也被系统中已知的许多漏洞潜在地威胁着。攻击者可以利用操作系统层面的许多漏洞来获得对GPU驱动程序的控制权，进而可以直接访问GPU的内存，或者通过篡改GPU页表来打破GPU应用程序之间的隔离，导致GPU中的敏感数据的泄露。考虑到如今的GPU计算通常会包含个人身份信息，如人脸信息和语音信息等，为GPU构建TEE保证计算数据安全是十分重要的。

目前，现有的GPU TEE工作主要是在拥有独立显存的GPU上进行的。这样的GPU拥有独立于系统DRAM之外的计算内存，相关的工作利用了该内存隔离的特性，构建了系统DRAM与GPU内存之间数据的安全传输通道，以此来构建TEE。然而，Arm边缘端的GPU并没有自身的独立内存，需要与系统共享DRAM，这意味着需要指定更严格的保护手段。除此之外，现有的GPU TEE大多都依赖于硬件修改，这导致相关工作难以被部署在现有的系统中。基于上述问题，我们提出了一种Arm终端设备上GPU TEE的构建方法——StrongBox，利用Arm架构现有的硬件特性来保护GPU的计算内存，以确保Arm边缘端GPU计算的安全性。

2. 相关背景及设定

我们假设攻击者具备操作系统内核层次的访问权限。为了获取GPU敏感计算数据的内容，他们可以破坏操作系统的GPU驱动，也可以直接访问共享内存中的GPU页表项、计算代码以及计算数据。除此之外，我们信任安全世界中的组件，并且不考虑密码学攻击、物理攻击以及侧信道攻击。

3. 设计与实现

StrongBox允许用户在一个不受信任的系统内安全地使用带有敏感计算的GPU应用程序。考虑如下的应用场景，用户执行部署的敏感GPU应用程序，使用密钥管理协议与StrongBox建立加密密钥。为了防止数据传输过程中的数据泄漏，用户将加密的数据发送到StrongBox。然后，StrongBox对数据进行保护和解密，允许GPU安全地处理它们。最后，用户从StrongBox取得加密的计算结果。

3.1 GPU的计算流程

在介绍具体的设计之前，这里我们先简要说明一下GPU计算程序的整个流程。一个GPU计算程序会包含多个计算任务（等同于CUDA里的GPU kernel的概念），在一个计算任务中还会包括多个并行的计算线程。如上图所示，一个GPU计算程序会经历以下流程：①GPU页表的构建（分配GPU可用的DRAM内存区域）；②GPU计算数据的载入；③GPU计算代码的载入；④GPU计算任务的提交；⑤GPU执行计算任务；⑥计算任务结束发送中断；⑦读取计算结果。对于多任务的GPU计算程序来说，需要多次提交任务（即④-⑥）以完成计算。此外，现有的工作表明，由于一些硬件和编程SDK的限制，Arm边缘端的GPU任务一般是串行执行的。

3.2 系统的整体架构

上图是StrongBox系统的架构图。图的左侧为系统的软件组成。为了减少系统的TCB大小，StrongBox没有将复杂的GPU驱动完全引入安全世界中，而是选择复用放在正常世界的GPU驱动来执行非敏感操作（如GPU内存资源的分配和计算任务的调度等），并将选择将轻量级的GPU守护（GPU Guard）和任务保护器（Task Protector）部署在EL3中。

图的右侧为与系统的相关的重要硬件部分，StrongBox没有对现有硬件进行任何修改，只是利用了TZASC和Stage-2 translation的硬件特性来实现相关的保护策略。除此之外，图中还对内存的区域进行了划分。StrongBox会保护Trusted RAM（存放安全世界代码和数据的区域）不被攻击，以及管理非安全世界对Secure Task RAM（一块预留在非安全世界的用于存放敏感GPU计算任务内容的内存）的访问权限。

3.3 保证敏感GPU任务执行的独占性

对于每个敏感的GPU计算任务，StrongBox会采用独占性来保证其在GPU上执行的安全性。当一个GPU敏感计算任务准备被提交到GPU上时，StrongBox会在GPU驱动中重新调度其他没有提交的非安全任务，避免它们提交到GPU上进行计算。而后，StrongBox会调用smc指令并进入安全世界中的GPU Guard中。GPU Guard会首先封锁GPU的MMIO端口，阻止任何恶意的与GPU交互的行为（如提交GPU任务）。而后GPU Guard会做进一步检查，确保当前GPU不存在其他非安全的计算任务，并与Task Protector进行交互以完成对GPU任务的检验与保护，包括计算代码的完整性校验、数据的加解密以及相关内存访问权限的设置。最后，GPU Guard会配置中断管理器（GIC），将GPU的中断设置为安全中断。在任务提交之后，StrongBox会返回非安全世界中，直至GPU计算任务完成发送的中断被安全世界捕获，系统会再次进入安全世界中对重置MMIO的封锁和中断的设置，以恢复执行环境。

3.4 动态细粒度内存保护

在一个GPU计算程序的执行过程中，GPU驱动需要频繁与GPU内存的非敏感区域进行交互，又由于敏感数据和代码在物理内存上的布局是分散的，因此我们结合TZASC和Stage-2 translation来设计了一种动态细粒度内存保护机制，在不同阶段细粒度地控制内存的访问权限。上图展示了在GPU计算程序的不同执行阶段下内存访问权限控制情况，StrongBox在内存分配时将内存划分为页表区域（GPU Page Table Region）和任务区域（Task Region），并分别进行保护。StrongBox会在第一个任务执行开始之后对整个GPU页表进行监视，任何写入都需要经过审查，避免恶意修改或构建地址映射。而对于Task Region里的数据和代码，在任务提交时和任务结束之后，StrongBox会分别对任务的代码及数据所在的内存进行保护，并进行代码的完整性检查和数据的加解密的相关操作。在默认情况下，StrongBox会在任务执行之前对任务所有的计算数据进行保护和解密，并在任务结束之后再将相关计算数据加密并解开保护。但这种默认的方法在保护多任务的计算程序时常常会导致不必要的开销，例如上一个任务的输出数据会作为下一个任务的输入数据进行处理。

3.5 多任务的保护开销优化

为了减少多任务之间不必要的操作，StrongBox只会在数据第一次被任务处理前进行解密，并且在最后一次被任务处理之后进行加密。因此，StrongBox提供了上述针对数据buffer的操作，以减少不必要的加解密和保护以及解保护操作所带来的开销。

4. 实验评估

为了评估StrongBox的性能开销，我们在JUNO R2开发板上实现了系统的原型，并使用了Rodinia benchmark来测试保护所带来的开销。根据应用计算量的大小，我们从中挑选了六个不同GPU计算应用，其中也包括单任务和多任务的计算应用，相关的参数和实验结果参照下列的表和图。

图5上半部数据表明StrongBox整体引入了4.70%-15.26%的性能开销，而下半部数据是在实现过程中面对闭源用户态驱动所引入额外内存开销，该开销可以忽略不计。除此之外，表2还对比了使用使用默认策略（No Optimization）和优化策略（StrongBox）所带来的性能对比，表中的TProtect代表保护和加解密数据所带来的开销。可以看到，在引入优化策略之后整体的性能开销大幅度下降。

5. 安全性分析

在安全性分析中，我们系统性地考虑了四种可能的攻击：①攻击者直接访问或修改Secure Task RAM内容；②利用恶意的GPU任务访问敏感内存；③伪造假的GPU以欺骗StrongBox；④破坏GPU驱动来实施攻击。我们的安全性分析表明，上述的攻击都没有办法窃取到敏感GPU计算程序中的数据。

6. 感想与致谢

在历时近3年的时间后终于发表论文，其中经历了无数次的方案探讨和争论。不管是方案的定型还是后续对于论文的修改则都是艰难的，在与闭源的用户态驱动斗智斗勇的过程中发现各种各样的bug，导致方案和实验反复的变动和修改。这一过程造成的感觉就是，对于这种无法控制进度也难以预测结果的的研究课题，及时放弃也是正常的。但在不懈努力和深入研究之后，我们最终还是有所收获。

最后，感谢张老师和宁老师的坚定指导，同样也感谢蚂蚁联合实验室给予的支持！