目录
Abstract
图形处理单元 (GPU) 可解锁大型语言模型和自动驾驶等新兴用例。他们处理大量敏感数据,其中安全性至关重要。 GPU 可信执行环境 (TEE) 通常以适度的开销为 GPU 应用程序提供安全性。最近关于 GPU TEE 的提议很有前景,但其中许多都需要硬件更改,而在生产环境中部署需要很长的准备时间。
本文介绍了 Honeycomb,这是一种基于软件、安全且高效的 GPU 应用 TEE。 Honeycomb 的关键思想是利用静态分析来验证 GPU 应用程序在加载时的安全性。通过与 CPU TEE 共同设计,并添加操作系统和驱动程序支持,Honeycomb 能够从可信计算基础 (TCB) 中删除操作系统和驱动程序。验证还确保系统内的所有应用程序都是安全的,从而能够通过 GPU 上的共享设备内存以简洁且安全的方式交换明文数据。
我们针对 AMD RX6900XT GPU 制作了 Honeycomb 原型。 Honeycomb 在五个代表性基准测试和总共 23 个应用程序上进行了评估,涵盖高性能计算、深度学习和图像处理的工作负载。结果表明,Honeycomb 对于保护现实世界的 GPU 应用程序来说既实用又高效。验证应用程序在 Honeycomb 上运行需要开发人员付出一定的努力。 TCB 比基于 Linux 的系统小 18 倍。安全的进程间通信速度提高了 529 倍。此外,运行 BERT 和 NanoGPT 等大型语言模型工作负载会产生约 2% 的开销。
Introduction
硬件加速器和深度神经网络的创新继续为我们的物理和数字存在提供个性化体验,重塑从智能家居[34]、虚拟现实[85]、个性化癌症药物[22]。提供如此亲密的体验在很大程度上依赖于大量有价值且敏感的用户数据,这需要 GPU 等硬件加速器提供高水平的安全和隐私支持。
可信执行环境 (TEE) [4] 将应用程序封装到飞地中以增强安全性。 TEE 在 enclave 和不受信任的主机环境之间强制实施强隔离,以便 enclave 内的应用程序可以以本机速度安全地处理纯文本数据。对于每个飞地,跨越其边界的所有流量都经过加密,以保持机密性和完整性。最近的原型 [28,44,45,83] 通过序列化对 GPU [28] 的安全访问、增强 GPU 硬件 [83]、定制 I/O 总线 [44] 或利用设备驱动程序中的共享功能[45]。
本文探索了一种替代方法——使用静态分析来验证相互不信任的 GPU 应用程序是否被限制在其飞地内。直观上,验证器检查 GPU 内核函数(简称 GPU 内核)的二进制代码,以表明所有可能的执行轨迹都保持了系统的机密性和完整性,因此这些应用程序可以安全地共享 GPU。这种方法具有三个好处。首先,它可以补充现有GPU的硬件限制。例如,Raspberry Pi 使用的 VC4 等低成本 GPU 由于缺乏相应的 MMU [16],因此允许对内存进行任意写入。验证器可以通过运行标准静态分析(例如 GPU 内核上的 def-use 分析和范围检查)来检测不安全行为并阻止攻击。此外,与在生产中部署新硬件支持相比,高级静态分析 [59] 可能会更快地缓解新攻击 [19, 21]。
第二个好处是它可以更有效地实现当前的 GPU TEE。将运行时检查转移到加载时间会将它们从关键路径中删除。此外,验证始终具有不相交上下文的应用程序可能会避免 TEE 实现在每次上下文切换期间刷新架构上下文(包括 TLB 和缓冲区队列)[28],从而提高性能。
最后,验证每个应用程序提供了系统范围的安全不变性,断言所有应用程序都是“好公民”。安全不变量使得 enclave 之间能够安全、高效地进行通信。自动驾驶 [89] 和视频分析 [66, 70] 等现实世界的应用程序在多级管道中处理数据。将管道的每个阶段分成不同的飞地并使用进程间通信(IPC)连接它们不仅可以提高模块化性和鲁棒性,而且还可以使用来自多个供应商的相互不信任的组件来组装管道[63, 74]。当前的 GPU TEE 侧重于加强隔离,例如,强制执行 GPU 设备内存的独占所有权 [83]。因此,两个相互不信任的 enclave 需要通过主机内存上的加密共享缓冲区来传输数据以进行 IPC。对于生产应用程序来说,开销是令人望而却步的。例如,自动驾驶车辆上的 GPU 处理高达 50 GB/s 的未压缩视频流,以做出及时的驾驶决策 [69]。将 50 GB/s 的数据复制到主机已经占用了商用高端 AMD Zen3 服务器总内存带宽的 30∼40%,更不用说加密/解密数据的开销了。直接在 GPU 中交换明文数据的能力大大减少了开销,从而使实际应用程序能够迁移到更加模块化和稳健的架构。
本文介绍了 Honeycomb 的设计和实现,这是一种基于软件、安全且高效的 GPU 应用 TEE。 Honeycomb在同一个GPU上运行多个互不信任的应用程序,促进应用程序之间高效、安全的数据交换。它支持从分子动力学模拟到神经网络训练和推理等常见 GPU 工作负载。 Honeycomb 的所有这些功能都建立在使用静态分析来限制 GPU 应用程序行为的理念之上。
Honeycomb 面临着三个挑战来实现这三个好处并为 GPU TEE 提供完整的、真实的解决方案。首先,它必须平衡验证器的功能和复杂性之间的权衡。配备定理证明器的验证器获得了它们的力量,但是 Honeycomb 必须在 TCB 中包含定理证明器,这很复杂(例如,Z3 4.12.2 有 ∼525 K 行代码)并且偶尔容易出错 [77]。另一方面,简单的验证器可能不足以在加载时验证常见的安全检查,需要插入正好位于性能关键路径上的额外运行时检查。
其次,Honeycomb 必须最大限度地减少端到端 TCB,以提供高度的安全信心。 GPU 应用程序的软件/硬件堆栈相当复杂。例如,AMD RX6900XT GPU 的编译器工具链和驱动程序各包含 200 万行代码。这些组件中的缺陷和漏洞是不可避免的[23,25,26],但它们不应该损害 Honeycomb 的安全性。
最后,Honeycomb必须为安全、高效的IPC提供系统级支持。前面提到的明文IPC只有在 Honeycomb 系统谨慎初始化数据副本并从/到严格受保护的内存区域时,GPU enclave 之间的数据传输才能安全地实现。
Honeycomb 通过三项关键技术解决了上述挑战。首先,Honeycomb 的验证器直接对二进制文件执行 GPU 内核的静态分析。它解码 GPU 内核的指令以重建控制和数据流。它使用标量演化 [6] 和多面体模型 [14] 对内存访问模式进行建模。我们的评估表明,该方法可以有效验证 GPU 内核中的大多数内存访问是否安全,因为现实世界的 GPU 内核往往经过良好优化,具有高度规则的控制流结构和内存访问模式。剩下的少数情况可以通过插入运行时检查来处理,GPU 内存层次结构也可以很好地容忍其延迟(§5)。
其次,Honeycomb 利用硬件隔离机制,并使用安全监视器 [54,79,90] 来验证系统中的交互,从而最大限度地减少对软件/硬件堆栈的信任。 Honeycomb 在由 AMD SEV-SNP [4] 提供支持的 CPU TEE 内推出了应用程序。验证器直接解析 GPU 二进制文件,以从 TCB 中删除编译器工具链。为了从 TCB 中删除用户空间和内核空间 GPU 驱动程序,Honeycomb 使用两个安全监视器来拦截和调节应用程序与 GPU 之间的所有流量:(1) 运行安全虚拟机服务模块 (SVSM) [4]在应用程序 enclave 内部,它在应用程序级别强制执行安全策略(例如,应用程序仅启动经过验证的内核),以及 (2) 在 GPU 的沙箱虚拟机管理程序内部运行的安全监视器,用于调节 GPU 驱动程序的行为(例如, ,驱动程序永远不应该将私有内存页映射到两个应用程序中)。此外,Honeycomb 还可以保护 CPU 和 GPU 之间的数据传输,以保护数据的机密性和完整性(§6)。
对于最后的挑战,Honeycomb 为安全 IPC 保留了虚拟地址空间的专用区域来交换明文数据。具体来说,Honeycomb将每个应用程序的虚拟地址空间分为四个区域:受保护的、只读的、读写的和私有的。验证器确保应用程序 GPU 内核只能修改私有区域。将元数据和接收缓冲区放入受保护的只读区域可防止用户应用程序篡改 IPC,从而将 Honeycomb 中的 IPC 减少为在设备内存中复制明文数据(§7)。
我们移植了五个具有代表性的基准测试套件,包括SpecACCEL 1.2基准测试套件[76]、ResNet18神经网络模型的推理应用程序[37]和BERT语言模型[29]、训练GPT语言模型的应用程序[48],以及一个执行 Canny 边缘检测的图像处理应用程序 [20],即总共 23 个应用程序。我们在配备两个 AMD EPYC 7443 24 核处理器和 AMD RX6900XT GPU 的服务器上对它们进行了评估。结果是有希望的。 TCB 是比基于 Linux 的系统小 18 倍。一个简洁的验证器足以静态验证大部分 GPU 应用程序的安全性。验证 ResNet18 和 BERT 等神经网络上的推理工作负载需要在 GPU 内核中添加零运行时检查。 BERT 和 NanoGPT 等大型语言模型工作负载的运行时开销约为 2%。 Honeycomb 中的 IPC 比使用主机上的加密共享缓冲区交换数据快 529 倍。本文做出以下贡献:
利用GPU内核的静态分析来限制GPU应用程序的行为,以提高安全性。我们对五个代表性基准测试套件的评估表明,该分析既实用又有效,可以通过最少的额外运行时检查来确定现实世界的 GPU 内核在加载时是否安全。
基于静态验证的GPU应用的轻量级、端到端安全执行环境的设计和实现。
一种 IPC 原语,可实现 GPU 应用程序之间安全高效的通信。静态分析和操作系统支持的共同设计带来了高度简洁的实现。
Background
为了理解 Honeycomb 的设计,首先回顾一下 GPU 的架构和编程接口,以及本文中使用的多面体分析的基本概念 [14, 35] 非常重要。
Architectures and programming interfaces of commodity GPUs
现代 GPU 为应用程序提供单指令、多线程 (SIMT) 编程模型。为了运行工作负载,应用程序向 GPU 的命令队列提交启动请求。该请求指定二进制函数(即 GPU 内核)、其参数、线程数,以及(可选)用于执行工作负载的用户可控的独立高速暂存器(即共享内存)的大小。线程被统一组织成网格和块。每个网格由相同数量的块组成,每个块由相同数量的线程组成。同一块中的每个线程都有自己的向量寄存器,但共享对共享内存的访问。该编程模型提供了一个概念视图,其中每个线程根据其自己的寄存器的值执行相同的指令。为了实现并行化,每个线程将输入加载到自己的寄存器中并并行计算输出。图 1 展示了在 SIMT 模型下将内存区域填充为特定值的示例。
GPU 的硬件架构与上面的 SIMT 模型非常匹配。典型的 GPU 由数千个处理元件 (PE) 组成,这些处理元件分为三级等级制度。最低层称为 warp,由以锁步方式执行的 32 或 64 个逻辑 PE 组成。微架构(例如,AMD GCN)可能会引入并行标量单元来在扭曲内执行统一计算,或者在物理 PE 上管道化计算以隐藏执行延迟。 Warp 进一步分为计算单元 (CU)。 CU 由向量寄存器池和共享内存组成。最后,单个 GPU 将多个 CU 封装在同一个芯片上。
硬件调度器跨应用程序复用硬件资源。最小调度单元是warp。它始终调度同一 CU 内块的所有线程束,因此块内的所有线程划分向量寄存器池并共享 CU 内相同的已分配共享内存。调度器不断调度所有的块和网格,直到执行完成。
GPU 驱动程序为每个 GPU 应用程序创建虚拟地址空间。它从主机的图形转换表 (GTT) 内存中为参数和命令队列分配缓冲区。缓冲区被映射到 GPU 上的虚拟地址空间,GPU 内核直接从中读取参数以及网格和块的布局。
AMD SEV-SNP
AMD SEV-SNP [4](安全加密虚拟化 - 安全嵌套分页)为在不受信任的云系统管理程序上运行的虚拟机 (VM) 提供硬件级别的增强安全功能。与其他 TEE 类似,SEV-SNP 支持远程认证以及针对不受信任的主机管理程序的应用程序虚拟机的数据机密性和完整性保证。存储器控制器中的专用硬件引擎在将数据发送到片外主存储器之前对数据进行加密。 SEV-SNP 还通过反向映射表 (RMP) 跟踪每个物理页的所有权,以便只有所有者才能写入内存区域。它进一步验证页面映射,以防止将单个页面恶意重新映射到多个所有者。通过这种方式,它能够减轻典型的数据损坏、重放、内存别名和内存重新映射攻击。
此外,SEV-SNP 还可以使用虚拟内存权限级别 (VMPL) 标记每个物理页。它类似于 x86 架构中的 Ring 0-3,但适用于 TEE VM。 VMPL 的用例之一是实施安全虚拟机服务模块 (SVSM)。 SVSM 在 VMPL0 上运行,来宾操作系统在 VMPL1 上运行。 SVSM 可以拦截系统调用和内存操作并充当安全监视器。
Polyhedral model
多面体模型已广泛应用于GPU程序的自动并行化和优化[8,14,92]。从概念上讲,它将每次内存访问表示为一组有序循环变量上的仿射表达式(即线性组合)。分析内存访问的影响(例如别名和范围)可以简化为解决整数变量的不等式。多面体模型与 GPU 内核配合良好,因为它们隐式地循环网格和块,并且高性能 GPU 内核具有规则的内存访问模式。
更具体地,迭代向量I = (i0, i1, . . . , in) ∈ Ds记录了循环变量i0, i1, …, in的值用于指令 s。域 Ds 称为迭代域。请注意,迭代器向量通常包括 GPU 内核中指令的网格索引 (gid) 和本地线程索引 (lid)。访问函数 As(w.r.t. 指令 s)将迭代器向量作为输入并输出实际的内存地址。
请注意,当 As 是仿射函数且 Ds 是仿射空间时,I 中的所有循环都有固定的步长。为了简单起见,我们将访问函数表示为向量,其中每个元素表示迭代向量的相应维度的系数。访问函数和迭代向量的点积就是实际的内存地址。我们还引入了一个额外的维度,该维度在迭代向量的末尾始终具有值 1,以便访问函数可以以统一的方式表示恒定的偏移量。
图 2 显示了图 1 中内核的访问函数,内核用一个值填充一定范围的内存。对值的仿射运算直接转换为对相应访问函数的向量形式的仿射运算(例如,A5=dim·A3+A4),前提是dim在整个分析中是一个常数。然而,GPU 内核实际上从内存加载 dim。在这种情况下,Honeycomb 中的安全不变量可确保值 dim 在整个执行过程中保持不变,以便分析保持有效。
Threat model
在本文中,我们采用了与之前关于 GPU 安全执行环境的研究类似的威胁模型 [44,45,83]。攻击者控制整个软件堆栈,包括编译器工具链、操作系统、虚拟机管理程序和设备驱动程序。它还可以物理访问服务器硬件并可以嗅探 PCIe 流量。我们假设主机 CPU 具有 TEE 功能,例如 AMD SEV-SNP 或 Intel TDX [43],GPU 具有硬件随机数生成器或性能计数器来收集用于加密用途的熵。我们还假设用户知道服务器硬件的规格及其连接方式,例如GPU插在哪个PCIe插槽上。最后我们假设Honeycomb能够与GPU建立可信的MMIO路径。我们的原型使用 AMD SEV-TIO [1] 来建立它,但这样的路径也可以使用其他安全 I/O 总线 [44, 65] 来实现,或者为服务器配备篡改检测机制 [75] 并建立使用虚拟机管理程序 [94] 到 GPU 的可信 I/O 路径。我们将细节推迟到第 8 节。
攻击者可以在 Honeycomb 中启动应用程序,改变编译器工具链的结果,并篡改服务器的物理内存。此外,攻击者还可以篡改 DMA 缓冲区。然而,我们信任 GPU 的设备内存,因为现代 GPU 通常使用 2.5D/3D 硅中介层将设备内存集成在同一封装内。我们假设对手无法观察到或损坏其中存储的数据[83]。支持集成 GPU 超出了本文的范围。
与之前的 GPU TEE [44, 83] 类似,对可信硬件的旁路攻击 [17, 40, 82, 86] 超出了本文的范围。 Honeycomb 依靠丰富的正交工作集来缓解这些问题 [9, 80]。可用性和拒绝服务攻击也超出了范围。
在这种威胁模型下,Honeycomb 应确保在同一 GPU 上运行的多个相互不信任的应用程序的机密性和完整性。对手无法篡改应用程序的 CPU 和 GPU 部分的代码、数据和控制流。
Overview
Honeycomb的整体架构如图1所示。 Honeycomb 提供统一的 TEE,涵盖应用程序的 CPU 和 GPU 部分。 Honeycomb 在 AMD SEV-SNP TEE VM 内启动应用程序。它首先在 VMPL0 处启动安全 VM 服务模块 (SVSM)。 SVSM 引导 BIOS、客户 Linux 内核,最后引导 VMPL1 上的用户空间应用程序。 SVSM 规范应用程序和 GPU 之间的所有交互。回想一下,在 CPU TEE 中,数据以明文形式存储在 CPU 包中。它们仅在离开片外主存储器时才被加密。在 Honeycomb 中,设备内存上的数据以解密方式存储,并且 SVSM 在将它们发送到主机时对其进行加密。读取数据的路径类似。
应用程序向 Honeycomb 请求 GTT 内存以与 GPU 交互。一块 GTT 内存可以用作内存副本的暂存缓冲区(映射到用户级地址空间),或者用作命令队列的后备缓冲区(只能由 SVSM 访问)。在这两种情况下,SVSM 都会检查访问权限以调节 GPU 和应用程序之间的安全内存传输 [83],并使用适当的参数启动经过验证的 GPU 内核。请注意,虽然 Honeycomb 当前的实现基于 AMD SEV-SNP,但我们的设计适用于其他 VM TEE,例如 Intel TDX。
Honeycomb 将 GPU 隔离在沙箱虚拟机内。沙箱内的安全监视器(SM)是运行在Linux内核下的虚拟机管理程序。 SM 管理驱动程序和 GPU 之间的所有交互。它确保 GPU 遵循预期的初始化序列,并跟踪设备内存页面的所有权,以防止应用程序之间意外共享设备内存。
要执行 GPU 内核,应用程序首先将包含 GPU 内核的 GPU 二进制文件加载到设备内存中。 Honeycomb 中的验证器将 GPU 内核的二进制代码和附带的前提条件作为输入。它验证 GPU 内核中的每条内存指令只能访问虚拟地址空间的某些区域。请注意,有时无法确定实际的目标地址,直到应用程序执行内核参数的具体值(例如图 1 中的基数)。因此,我们引入前提条件,它指定对参数的约束,以便验证器可以静态分析边界。 Honeycomb 在运行时检查先决条件,以确保攻击者无法破坏分析。
验证器解码 GPU 内核的指令以重建其控制和数据流。它使用标量演化和多面体模型将每个内存指令的目标地址表示为符号表达式。它插入前提条件来推理目标地址的边界,并确保该地址位于指定区域内。分析是合理的,这意味着一旦访问被证明,对于所有可能的执行都是安全的。对于未确定的情况,例如间接内存访问 a[b[i]],Honeycomb 要求开发人员注释并添加运行时检查以通过验证。我们对现实世界基准测试套件的评估表明,开发和运行时性能的开销都很适中——常见的生产 GPU 内核(例如矩阵乘法)往往具有常规的内存访问模式。该分析足以捕获模式,因此几乎不需要注释。
验证器强制执行访问控制,有效地将 GPU 应用程序的虚拟地址空间划分为四个区域:受保护、只读 (RO)、读写 (RW) 和私有,每个区域都有不同的访问策略。例如,应用程序被禁止修改RO区域,但具有对私有区域的完全访问权限。 Honeycomb 将二进制代码和参数放置在 RO 区域中,以便恶意内核无法在通过验证后动态修改代码。此外,Honeycomb 通过将缓冲区映射到不同区域来实现安全 IPC。 Honeycomb 将 IPC 缓冲区映射到发送方的受保护区域和接收方的 RO 区域。发送方调用受信任的 send() 端点将明文数据复制到 IPC 缓冲区,其中机密性和完整性均得到保留。
Validator
Security monitors
Secure and efficient IPC
Discussion
Establishing a trusted I/O path to the GPU
当服务器没有 AMD SEV-TIO 或其他安全 I/O 总线时,Honeycomb 可以利用先前的工作 [94] 建立到 GPU 的可信 I/O 路径。在高层上,Honeycomb 在启动过程开始时获得对 I/O 路径的独占控制,然后任何不受信任的组件都可以访问 GPU。特别是,服务器首先启动到 SM,整个启动过程通过 SecureBoot [55] 进行验证和证明。其次,SM 枚举 PCIe 总线以发现 GPU 的 MMIO 区域及其所有上游 PCIe 交换机。然后,它初始化 IOMMU 以保护 MMIO 区域免受虚拟机管理程序和其他设备的 DMA 缓冲区的任何未经授权的访问。它进一步对 PCIe 访问控制服务 (ACS) 寄存器 [5] 进行编程,以阻止未经授权的点对点 PCIe 事务。经过这些步骤之后,Honeycomb 就可以继续正常的启动过程了。通过正确配置 IOMMU 并禁用对等 PCIe 访问,上述初始化过程足以将 GPU 的 MMIO 区域与服务器内部不受信任的软件组件和其他 I/O 设备隔离[94]。 Honeycomb 依靠额外的篡改检测机制来检测和减轻物理攻击。
在上述替代设置中,TCB 必须包括启动过程中使用的所有组件,例如 UEFI BIOS。必须采用SM和不可信管理程序来支持嵌套虚拟化[11]。没有篡改检测机制的遗留系统的威胁模型较弱,因为它们无法防御物理攻击。
Remote attestations
用户应用程序需要证明其自己的SEV-SNP VM和沙箱VM以验证执行环境的安全性。它遵循标准程序来证明自己的虚拟机。证明还保证 GPU 的有效执行上下文,因为 SVSM 是证明的一部分,并且它调节 GPU 执行上下文。请注意,SM 是 TCB 的一部分。 SM 维护用于沙箱虚拟机认证的公私密钥对。用户应用程序使用密钥对对SM进行身份验证,以验证沙箱VM的安全性。
Security analysis
Attacking the software stack
攻击者可能会尝试通过破坏 Honeycomb 中的验证来启动恶意 GPU 内核。一些可能的攻击包括使用无效参数使前提条件无效,通过操纵溢出寄存器的值来破坏数据流,以及修改分支的代码或目标地址以劫持控制流[18]。回想一下,SEV-SNP 确保用户应用程序无法篡改 SVSM。 SVSM 在执行 GPU 内核之前重新评估带有参数的先决条件以防御第一次攻击。 Honeycomb保护RO和RW区域的代码和溢出区域,以防御第二次和第三次攻击。特别是,验证器会分析 GPU 内核中的每个全局内存访问,以确保其无法篡改保留区域,从而保持验证的完整性。
攻击者可能会篡改系统软件堆栈,包括 GPU 驱动程序、主机操作系统和虚拟机管理程序,从而破坏 Honeycomb 的安全性。为了访问驻留在设备内存中的明文信息,他们可能会执行代码来构造恶意 MMIO 请求、发起未经授权的 DMA 请求,或者将设备内存从其他应用程序映射到不同的地址空间。这是无效的,因为 Honeycomb 中的 SM 调节来自系统软件堆栈的所有 MMIO 和 DMA 请求。通过拦截 MMIO 请求,它可以强制隔离地址空间并防止意外共享。它还强制要求与外部世界的数据通信全部加密并经过身份验证。
攻击者可能会更改 GPU 固件或偏离指定的启动序列以控制 GPU。这是无效的,因为 GPU 硬件会验证固件的完整性 [55],而 Honeycomb 中的 SM 会在 GPU 初始化期间验证启动序列。
Attacking the hardware stack
攻击者可能会介入主机内存来尝试更改可信组件,例如 Honeycomb 中的 SVSM。这是无效的,因为 SEVSNP 包括验证可信组件完整性的证明程序。 SEV-SNP 还结合了内存加密和完整性来防御攻击。
攻击者可能会干预 PCIe 结构以插入 MMIO 或 DMA 请求,或篡改现有请求以访问驻留在设备内存中的明文信息。或者,它们可以将 GPU 的 MMIO 区域映射到另一个 I/O 设备,或者启动点对点 PCIe 事务以与 GPU 交互。当 GPU 连接到安全 I/O 总线时,这两种类型的攻击都是无效的 [1, 44, 65]。当使用第 8 节中描述的替代初始化过程来建立可信 I/O 路径时,Honeycomb 使用篡改检测机制检测并阻止第一类攻击[75]。为了防御第二种类型的攻击,Honeycomb 对 IOMMU 和 PCIe ACS 寄存器进行编程,以在启动任何不受信任的组件之前获得对 GPU MMIO 区域的独占控制。此外,攻击者可能会对映射到 PCIe 配置空间中的寄存器的 I/O 端口进行写入,以期重新定位 GPU 的 MMIO 区域。 Honeycomb 能够识别并阻止潜在的攻击,因为硬件拓扑唯一确定映射 [94]。攻击者还可能绕过 IOMMU 在 I/O 设备和 GPU 之间发起点对点 PCIe 事务。 Honeycomb 能够阻止攻击,因为它对 PCIe ACS 寄存器进行编程,以防止未经授权的点对点 PCIe 事务。
我们的威胁模型假设攻击者无法窥探或篡改独立 GPU 的设备内存。攻击者还可以尝试执行行锤攻击[51],这可以通过正交研究来缓解[7,67,87]。
Side-channel attacks
攻击者可能会尝试利用各种定时和电源侧通道。捍卫它们超出了本文的范围,可以利用正交工作 [9, 80]。
Implementation
Evaluation
Experiment setup
TCB
End-to-end performance
Overheads
IPC performance
Developer experience
Related work
TEE designs on GPUs
GPU TEE 在相互不信任的飞地之间强制实施隔离。 Graviton [83] 使用 RMP 表增强了 GPU 硬件,以隔离 enclave 之间的物理内存页面。 Telekine [42] 基于 Graviton 构建,删除了有关 GPU 内核执行时间的侧通道,从而增强了整体隔离信心。 HIX [44] 和 CRONUS [45] 依靠 GPU 驱动程序的隔离机制来正确保护和隔离应用程序。然而,现代 GPU 驱动程序本质上很复杂,甚至隔离等安全功能也容易出现漏洞 [24, 27]。 StrongBox [28] 利用 SoC 上的安全 IOMMU在集成 GPU 上隔离 enclave。它需要更新 IOMMU 并刷新 IOMMU TLB 以在不同的执行环境之间切换。
HETEE [95] 部署了一个带有商用 GPU 的防篡改服务器集群。这些服务器通过基于 FPGA 的集中控制器访问安全加速器盒,通过物理隔离实现隔离。 Visor [66] 专注于云中的隐私保护视频分析。它结合了应用程序级别的不经意算法和系统级别的混合 TEE 以提供隔离。
Honeycomb 通过静态分析限制 GPU 应用程序的行为来强制隔离。 Honeycomb 的方法补充了现有 GPU 的硬件限制,减少了开销,并创造了优化机会,例如通过 IPC 直接共享数据。在当前 GPU TEE 中执行 IPC 需要通过主机上的加密共享内存缓冲区来回复制数据。 Honeycomb 结合了静态分析和系统级设计的限制,以减少 IPC 在设备内存中复制明文的次数。 Honeycomb 中的 IPC 比传统方法快两个数量级,使实际应用程序能够以适度的开销采用更加模块化的架构。
GPU TEE 还强制执行 enclave 和不可信主机环境之间的隔离。他们需要在 CPU TEE 内运行的应用程序和 GPU 之间建立安全的通信通道。之前的工作在 GPU 硬件 [83]、PCIe 结构 [44] 中实现了端到端安全通信通道,或利用 SoC 内部的安全 IOMMU [28, 45]。 Honeycomb 利用安全 I/O 总线 [1,44,65] 或基于软件的解决方案 [94] 的现有工作来建立安全通信通道。
Crypto-based secure computing on GPUs
现代密码学的最新进展为隐私保护计算提供了理论上可证明的解决方案,例如多方计算(MPC)、乱码电路(GC)和同态加密(HE)。这些算法已用于实现机器学习和数据分析的安全 GPU 计算。在 GAZELLE [47] 之上,Delphi [56] 使用 GPU 来加速基于 HE 的线性运算,并选择性地取代昂贵的基于 GC 的非线性 ReLU 运算。具有多项式近似的tor。 CryptGPU [78] 进一步在 GPU 上以基于 MPC 的协议实现了线性和非线性运算。它将秘密共享值计算嵌入到浮点运算中,有效地利用 GPU 硬件单元。 GForce [61] 相反,专注于推理,并通过应用新的量化方法和采用 GPU 友好的协议来解决非线性算子的高延迟问题。最后,Piranha [84] 是一个通用的模块化框架,用于在 GPU 上加速基于秘密共享的 MPC 协议,利用优化的基于整数的 GPU 内核和内存高效的就地计算。
加密解决方案不会将明文值保留在不受信任的平台中,因此它们更能抵抗侧通道漏洞。然而,与本机处理相比,它们的计算成本要高得多,导致速度大幅减慢。专用硬件 [50,71,72] 和可信硬件单元 [93] 已被提出来加速 HE 和 MPC,但都需要进行重大的硬件更改。
Slalom [81]采取了不同的方法。它使用CPU TEE来计算非线性部分,并将加密数据卸载到不受信任的GPU来处理线性运算。机密性和完整性均得到保证。 DarKnight [36]通过更好的加密方法进一步优化了流程,大大降低了CPU和GPU之间的通信成本以及CPU TEE涉及的计算量。
Secure operating systems
在提高操作系统的安全性方面已有丰富的研究,包括明确安全策略[73, 90]、在操作系统内核中应用安全语言[13, 41]以及通过形式验证证明属性[52, 54]。 Honeycomb 利用安全监视器和虚拟化等技术 [10, 79] 将 Linux 内核和设备驱动程序从 TCB 中删除。
Software fault isolation (SFI)
轻量级故障隔离 [46,57,88] 已被证明在 x86 架构上有效。本质上,Honeycomb 中的验证是 GPU 内核的 SFI 的一种形式。然而,Honeycomb 将 SFI 与替代内存布局和其他系统级支持相结合,将故障隔离扩展到安全执行环境。
Polyhedral analysis
有大量关于利用多面体表示进行循环分析和转换的文献[8,14,35,58]。研究人员已将这些方法扩展到更一般的情况[12]。 Honeycomb 使用多面体分析对 GPU 内存访问的影响进行建模,并确保内存访问符合安全策略。
Conclusion
Honeycomb 证明静态分析(验证)是一种实用且灵活的技术,可增强 GPU 应用程序的安全性。结合硬件和操作系统支持,Honeycomb 的验证保证了强大的系统范围不变量,例如应用程序中的每个内存访问都与安全策略符合。因此,Honeycomb 将 TCB 的大小减少了 18 倍,并提供了比传统方法快 529 倍的安全 IPC 原语。
Honeycomb 对五个代表性基准测试套件、总共 23 个应用程序的评估表明,Honeycomb 实用且高效,可以为实际应用程序提供安全的 GPU TEE。它需要在 GPU 内核中插入很少或根本不需要运行时检查来验证它们,因此运行时开销很小。 BERT 和 NanoGPT 等大型语言模型工作负载在 Honeycomb 上的运行时开销约为 2%。
当今GPU应用的蓬勃发展需要GPU软件/硬件堆栈的不断创新。我们在 Honeycomb 上的经验表明,静态分析具有很大的潜力,可以帮助探索完整软件/硬件堆栈中的新颖设计并加速创新。