【论文分享】Graviton: Trusted Execution Environments on GPUs 2018’OSDI

本文主要是介绍【论文分享】Graviton: Trusted Execution Environments on GPUs 2018’OSDI，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！

Abstract

我们提出了 Graviton，一种支持 GPU 上可信执行环境的架构。 Graviton 使应用程序能够将安全和性能敏感的内核和数据卸载到 GPU，并独立于 GPU 上运行的其他代码和主机上的所有软件（包括设备驱动程序、操作系统和虚拟机管理程序）来执行内核。 Graviton可以集成到现有的GPU中，硬件复杂度相对较低；所有更改仅限于外围组件，例如 GPU 的命令处理器，而不对现有 CPU、GPU 内核或 GPU 的 MMU 和内存控制器进行更改。我们还建议对 CUDA 运行时进行扩展，以便在 GPU 上安全地复制数据和执行内核。我们已经在现成的 NVIDIA GPU 上实现了 Graviton，使用模拟来实现新的硬件功能。我们的评估表明，开销较低（17-33%），进出 GPU 的流量加密和解密是开销的主要来源。

Introduction

最近的趋势，例如收集和处理的数据量激增、摩尔定律 [16] 的产量下降、云计算和深度学习等应用程序的使用不断增加，推动了 GPU、FPGA 等加速器的广泛使用[ 37]和TPU[20]。几年后，预计公共云中的大部分计算周期将由加速器贡献。

与此同时，数据泄露的频率和复杂性不断增加，使我们认识到我们需要更强大的安全机制来保护敏感代码和数据。为了解决这个问题，硬件制造商已开始以可信执行环境 (TEE) 的形式将可信硬件集成到 CPU 中。 TEE，例如 Intel SGX [28] 和 ARM Trustzone [1]，可以保护敏感代码和数据免受系统管理员和可能利用内核漏洞并控制整个软件堆栈（包括操作系统和虚拟机管理程序）的攻击者的侵害。然而，现有的 TEE 仅限于 CPU，不能用于卸载计算以加速的应用程序。这种限制导致了安全性和性能之间的不期望的权衡。

向加速器添加 TEE 支持具有挑战性有几个原因。对于大多数加速器，设备驱动程序负责管理设备资源（例如设备内存）并完全控制设备。此外，高吞吐量加速器（例如 GPU）通过集成大量核心并使用高带宽内存来满足其海量带宽需求来实现高性能[4, 11]。内核、内存管理单元或内存控制器的任何重大更改都可能导致无法接受的巨大开销。例如，通过加密引擎和 Merkle 树提供内存机密性和完整性将显着影响可用内存容量和带宽，而这已经是加速器上的宝贵商品。类似地，在地址转换期间通过类似 SGX 的检查强制执行内存隔离会严重利用加速器，因为它们对地址转换延迟很敏感 [35]。

在本文中，我们研究了在 GPU 上支持 TEE 的问题。我们描述了将计算卸载到 GPU 的应用程序的攻击面，并发现将资源管理委托给设备驱动程序会创建一个巨大的攻击面 [26, 36]，导致页面别名攻击，如果没有硬件支持，则很难防御。有趣的是，我们还发现 GPU 和 CPU 之间的架构差异在某些方面减少了攻击面。例如，所有最新的服务器级 GPU 都使用 3D-IC 设计，其中堆叠内存通过硅中介层连接到 GPU 核心 [4, 11]。与使用 PCB 上的铜基走线连接到 CPU 的非封装内存不同，攻击者很难打开 GPU 封装并窥探 GPU 和堆栈内存之间的硅互连，这很容易被窥探和篡改。即使物理访问 GPU。因此，将封装内存包含在信任边界内是一个合理的假设。

基于这些见解，我们提出了 Graviton，一种在 GPU 上支持 TEE 的架构。在 Graviton 中，TEE 采用安全上下文的形式，即 GPU 资源（例如设备内存、命令队列、寄存器）的集合，这些资源以加密方式绑定到公钥/私钥对，并与主机上不受信任的软件隔离（包括驱动程序）和所有其他 GPU上下文。 Graviton 保证一旦创建了安全上下文，其资源只能由拥有相应私钥的用户应用程序/运行时访问。只要密钥受到保护，不受对手攻击（例如，密钥托管在 CPU TEE 中），对手就无法访问上下文的地址空间。 Graviton 支持两个附加原语：用于生成上下文状态和平台的远程可验证摘要的测量，以及安全内存分配和释放，用于让设备驱动程序动态分配和释放内存而不影响安全性。

Graviton通过重新定义GPU驱动程序和硬件之间的接口来实现强大的安全性。具体来说，我们阻止驱动程序直接访问安全敏感资源，例如页目录、页表和其他包含敏感代码和数据的内存。相反，我们要求驱动程序通过 GPU 的命令处理器路由所有资源分配请求。命令处理器跟踪资源的所有权，并确保对手无法访问安全上下文所拥有的资源。命令处理器还确保资源在分配到安全上下文时正确初始化，并在破坏时进行清理，从而防止利用不当初始化的攻击[23,36,52]。

我们的设计具有几个关键属性，包括硬件复杂性低、性能开销低和加密敏捷性。 Graviton 不需要更改 GPU 核心、MMU 或内存控制器。所有变化仅限于外围组件，例如GPU命令处理器和PCIe控制引擎；这主要是由于封装内存可以信任的假设。 Graviton 对 TEE 中可用的指令集没有限制。我们还展示了 GPU 运行时可以使用 Graviton 构建更高级别 API 的安全版本，例如内存复制、内核启动和流，这些可用于构建具有端到端机密性和完整性的应用程序。

我们在 NVIDIA Titan GPU、开源 CUDA 运行时 gdev [21] 和开源 GPU 驱动程序 nouveau [29] 上评估了我们的设计。在没有实现所建议的扩展的硬件的情况下，我们使用传递到主机的中断来实现和模拟扩展。我们使用一组代表性机器学习基准进行的评估表明，对于我们提供的安全级别，使用安全上下文运行计算密集型 GPU 应用程序的开销较低 (17-33%)。开销主要由内核启动命令和用户数据的经过身份验证的加密/解密的成本决定。

contributions

我们提出了 Graviton，一种在 GPU 等加速器上支持 TEE 的架构。即使攻击者可以控制主机上的整个软件堆栈，包括加速器驱动程序，Graviton 也能提供强大的安全特性。

我们定义了一个威胁模型，该模型信任 GPU 硬件，包括封装内存。

我们提出了一组用于实现 Graviton 的 GPU 硬件的最小扩展，并展示了如何使用这些扩展来设计具有端到端安全保证的应用程序。该设计无需更改 GPU 内核、MMU 或内存控制器，从而降低了硬件复杂性和性能开销。

Background

GPU

我们回顾了 NVIDIA GPU 架构和 CUDA 编程模型，以说明如何在 GPU 上卸载和执行计算任务。我们专注于架构的安全关键部分。

Software stack

用户空间应用程序使用用户空间 GPU runtime（例如 CUDA runtime）提供的 API，通过一段称为内核的代码对 GPU 执行单元进行编程，并在主机和设备内存之间传输数据。 GPU runtime 将每个 API 调用转换为一组 GPU 命令，用于配置设备并控制内核启动和数据传输。 GPU 驱动程序负责通过 PCI 总线将这些命令提交给 GPU 并管理设备内存。

Hardware

GPU（图 1）通过 PCI 控制引擎与主机 CPU 连接，该引擎通过内部总线与其余 GPU 组件连接。关键组件是命令处理器、计算和复制 (DMA) 引擎以及内存系统（包括内存控制器和内存芯片）。

PCI 控制引擎由 (a) 接收传入和传出 PCI 事务的 PCI 控制器和 (b) 主控制引擎组成，该主控制引擎公开一组由主机 CPU 访问的内存映射 IO (MMIO) 寄存器启用和禁用 GPU 引擎。

命令处理器（也称为通道引擎）接收设备驱动程序通过一组称为通道的命令队列提交的命令，并在它们空闲时将它们转发到相应的引擎。通道通过一组称为通道控制区域的内存位置进行配置，该区域映射到 MMIO 上并由命令处理器提供服务。

计算引擎由一组图形处理集群（GPC）和一个共享的二级缓存组成。每个 GPC 由许多流式多处理器 (SM) 组成，用于运行 GPU 内核。每个 SM 由多个核心和私有内存层次结构组成，包括只读缓存、L1 缓存和应用程序管理的内存。 GPU 内核指定要创建的线程数量，并将其组织成线程块和网格。线程块被划分为warp，其中每个warp是每个SM上的调度单位。属于同一线程块的线程共享缓存和应用程序管理的内存。

现代 GPU 通过内存控制器支持虚拟内存，内存控制器具有用于地址事务的页表遍历器和 TLB 层次结构。例如，在 NVIDIA Volta 中，L1 缓存是虚拟寻址的，L2 缓存是物理寻址的。 GPU 在访问 L2 缓存时使用共享的两级 TLB [19]。

Context and channel management

GPU 上的执行是基于上下文的。 CUDA 上下文表示执行 CUDA 内核所需的资源和状态（内存、数据等）的集合。资源被分配给上下文来运行计算任务，并在上下文被销毁时被释放。每个上下文都有自己的地址空间。 GPU 使用通道将上下文的地址空间与其他上下文隔离。通道是向 GPU 提交命令的唯一方式。因此，每个GPU上下文分配至少一个GPU通道。

为了创建通道，设备驱动程序会在设备内存中分配通道描述符和多级页表（图 2 和 3）。例如，一个简单的二级页表由页目录（PGD）和许多叶页表（PGT）组成。驱动程序将通道描述符地址写入通道控制区，以及通道描述符中的页目录地址。页目录由指向叶页表的条目组成，叶页表包含虚拟到物理的映射。页表通常支持小页 (4KB) 和大页 (128KB)。设备驱动程序通过 BAR 和 PCI 总线更新所有这些数据结构。

创建通道后，设备驱动程序会为一些通道特定的数据结构分配设备内存，包括 (a) 通道和计算引擎的内部上下文，(b) 用于主机 CPU 和计算引擎之间同步的栅栏缓冲区。 GPU，以及©中断缓冲器，用于通知主机GPU引擎产生的中断。

Command submission

命令处理器负责获取软件堆栈提交的命令并将它们转发到适当的 GPU 引擎。图 4 显示了用于命令提交的数据结构。驱动程序在内核空间中分配两个缓冲区，一个命令缓冲区和一个环形缓冲区。命令缓冲区内存映射到用户空间。运行时将命令组推送到命令缓冲区，使用每组的大小和偏移量更新通道的环形缓冲区，然后通过 MMIO 使用指向命令组的指针更新称为 PUT 寄存器的寄存器。当更新 PUT 寄存器时，命令处理器从缓冲区获取命令组，并更新 GET 寄存器以通知运行时命令已被获取。

Programming model

接下来，我们概述将内核调度到 GPU 的主要阶段。

Initialization

希望使用 GPU 的应用程序首先创建 CUDA 上下文。在上下文创建过程中，runtime 为主机内存和设备内存之间的数据传输分配 DMA 缓冲区（图 2）。随后，应用程序将一个或多个 CUDA 模块加载到上下文中。对于模块中定义的每个内核，runtime 通过为 (a) 内核代码、(b) 内核使用的常量内存和 © 每个线程使用的本地内存分配设备内存，在 GPU 上创建相应的内核对象与内核相关。然后，runtime 通过 DMA 将代码和常量内存复制到设备内存。

Memory allocation

应用程序使用内存分配 API（cudaMalloc 和 cudaFree）分配设备内存来存储内核的输入和输出。内存分配由驱动程序提供服务，更新页目录和页表。

Host-GPU transfers

当应用程序发出主机到设备的复制时，runtime 将命令组推送到上下文的通道，将源和目标的虚拟地址传递给复制引擎。配置引擎后，它将虚拟地址转换为物理地址并启动 DMA 传输。

Kernel dispatch

当应用程序执行内核时，运行时将命令组传递给命令处理器，其中包括内核的上下文、代码段的基地址、入口程序计数器、网格配置和内核的环境，其中包括堆栈和参数值。命令处理器使用这些参数来初始化计算引擎，而计算引擎又会初始化并调度 GPU 核心上的计算。

Sharing

GPU 可用于使用抢占式多任务处理 [33, 42]、空间多任务处理 [2, 34]、同时执行 [47]、多进程服务 [ 30]，或虚拟化[25]。在这种情况下，主机（驱动程序）有责任使用通道抽象和虚拟内存来隔离内核。虽然空间多任务提倡SM分区，但它仍然共享内存资源并依赖虚拟内存进行隔离。即使在支持 SR-IOV 和硬件分区资源的设备（例如 AMD MxGPU）中，系统软件仍然负责将虚拟设备分配给虚拟机。

Intel SGX

可信执行环境或飞地（例如英特尔 SGX）可保护代码和数据免受系统中所有其他软件的影响。借助操作系统支持，不受信任的托管应用程序可以在其虚拟地址空间中创建飞地。一旦飞地初始化，飞地内的代码和数据就会与系统的其余部分（包括特权软件）隔离。

Intel SGX 通过将 enclave 代码和数据存储在称为 Enclave Page Cache (EPC) 的数据结构中来强制隔离，其位于 DRAM 的预配置部分，称为处理器保留内存 (PRM)。处理器确保 enclave 外部的任何软件都无法访问 PRM。但是，Enclave 内托管的代码可以访问非 PRM 内存和属于 Enclave 的 PRM 内存。 SGX 包含一个内存加密引擎，可对逐出内存的 enclave 数据进行加密和验证，并确保完整性和新鲜度。

除了隔离之外，飞地还支持远程证明。远程证明允许远程挑战者在飞地中建立信任。在英特尔 SGX 中，Enclave 中托管的代码可以请求quote，其中包含许多 Enclave 属性，包括 Enclave 初始状态的度量。quote由特定于处理器的证明密钥签名。远程挑战者可以使用英特尔的证明验证服务来验证给定的quote是否已由有效的证明密钥签名。挑战者还可以验证飞地是否已初始化为预期状态。一旦飞地经过验证，挑战者就可以与飞地建立安全通道（使用安全密钥交换协议）并向飞地提供加密代码或数据加密密钥等机密。

Threat Model

我们认为一个强大的对手控制着整个系统软件，包括设备驱动程序、客户操作系统和虚拟机管理程序，并且可以物理访问所有服务器硬件，包括 GPU。显然，这样的对手可以读取和篡改任何受害者进程的代码或数据。攻击者还可以访问或篡改 DMA 缓冲区中的用户数据或受害者应用程序向 GPU 提交的命令。这使得攻击者可以控制属性，例如正在执行的内核的地址和传递给内核的参数。攻击者还可以直接通过 MMIO 访问设备内存，或者将用户的 GPU 上下文内存空间映射到攻击者控制的通道。在多任务 GPU 中，恶意内核可以被调度到 GPU，从而访问属于受害者上下文的内存。即使在虚拟化环境中（例如，即使设备支持 SR-IOV），这些攻击也是可能的，因为 VM 和虚拟设备之间的映射是由管理程序控制的。

对服务器进行物理访问的对手可以对主机内存总线和 PCIe 总线发起窥探攻击。然而，我们确实信任 GPU 和 CPU 软件包和固件，并假设对手无法提取软件包中的秘密或破坏状态。这意味着我们相信 CPU 能够保护 TEE 内托管的代码和数据。侧信道攻击（例如，基于推测执行、访问模式和计时）以及拒绝服务攻击也不属于本文的讨论范围。侧通道是可信硬件的一个严重问题[10,12,22,38,45,50]，建立有效的对策仍然是一个悬而未决的问题。在 Graviton 中，我们使用 TEE 来托管用户应用程序和 GPU runtime。

与不可信的主机内存不同，我们信任封装的 GPU 内存，因为 GPU 核心使用硅中介层连接到内存，这使得攻击者很难发起窥探或篡改攻击。针对堆叠集成电路 (IC) 出现了一类新兴的攻击，例如封装组装器在 GPU 和内存芯片之间插入特洛伊木马芯片的攻击 [49]。开发针对这些攻击的缓解措施是一项持续的工作 [3]，超出了本文的范围。

即使在这种威胁模型下，我们也希望保证使用 GPU 的应用程序的机密性和完整性。具体来说，我们希望保证对手无法观察或篡改由在 CPU TEE 或本地计算机中运行的可信应用程序传输至 GPU 或从 GPU 传输的代码、数据和命令。最后，我们希望保证 GPU 计算的进行不受对手的干扰。

Overview

考虑执行矩阵乘法的 CUDA 应用程序（图 5），矩阵乘法是机器学习算法中的关键构建块。应用程序创建一个新的 CUDA 上下文（隐式地在第一个 CUDA API 调用上），为主机和设备内存中的输入和输出矩阵分配内存，填充矩阵，然后调用 GPU 上的矩阵乘法内核（未显示），传递指向设备内存和其他内核参数的指针。内核完成后，应用程序将结果复制到主机内存中并释放 GPU 上分配的内存。

如前所述，即使该应用程序托管在 CPU enclave 中，拥有服务器特权访问权限的攻击者也可以轻松恢复矩阵内容和结果。我们只需将其与 Graviton 的 CUDA runtime 版本链接起来，即可强化此应用程序以抵御此类攻击。 Graviton 的runtime 版本在支持 Graviton 的 GPU 上创建安全上下文（而不是默认上下文）。在此过程中，运行时对 GPU 进行身份验证，并与 GPU 的命令处理器建立安全会话，会话密钥存储在 CPU enclave 内存中。

runtime 还提供了 cudaMalloc 的自定义实现，它调用设备驱动程序来分配 GPU 内存，并另外验证分配的内存是否无法从任何其他上下文或主机访问。 cudaMemcpy 的安全实现确保主机和 GPU 之间的所有传输（包括代码和数据）均使用攻击者无法访问的密钥进行加密和身份验证。 cudaLaunch 的实现通过安全会话将加密的启动命令发送到 GPU 的命令处理器。最后，cudaFree 的实现授权 GPU 的命令处理器从页表中取消映射先前分配的页面，并清理其内容，使驱动程序能够重用这些页面而不会泄漏敏感数据。

Graviton Architecture

在本节中，我们将描述对现有 GPU 架构的扩展，以支持安全上下文。

Remote Attestation

支持 Graviton 的 GPU 支持远程证明，以在安全上下文和远程挑战者之间建立信任。对证明的硬件支持类似于 TPM；我们需要（a）一个秘密，称为根认可密钥（EK），在制造过程中被烧录到设备的efuses中；（b）一个用于非对称密钥生成和签名的加密引擎。 EK 是证明的信任根，永远不会离开 GPU 包。在启动期间，GPU 会生成新的证明密钥 (AK) 对，并将私钥安全地存储在命令处理器内。 GPU 还使用 EK 对 AK 的公共部分进行签名，并将其提供给设备驱动程序，然后设备驱动程序发送将 AK 签名给受信任的 CA。 CA 使用制造商提供的公共认可密钥存储库来验证签名，并生成签名的 AK 证书。该证书由设备驱动程序存储，并在安全上下文创建期间使用，以向挑战者证明 GPU 持有并保护私有证明密钥。

Secure Context Management

在 Graviton 中，安全上下文由一个或多个安全通道组成。我们使用用于创建、管理和销毁安全通道的新命令扩展了 GPU 的命令处理器（图 6）。

使用命令 CH CREATE 创建安全通道，该命令需要通道标识符和公钥 UK pub 作为参数。收到请求后，命令处理器会生成新的通道加密密钥 (CEK)，用于加密发布到该通道的命令。公钥 UK pub、CEK 和计数器存储在设备存储器中只能由命令处理器访问的区域中。 CH CREATE 可用于通过传递相同的 UK pub 来创建与相同安全上下文关联的多个通道，在这种情况下，所有此类通道将使用相同的 CEK。

生成 CEK 后，命令处理器通过将 CEK 安全地传输到受信任的用户空间运行时来建立会话。命令处理器使用 UK pub 加密 CEK，并生成包含加密的 CEK 和 UK pub 哈希值的报价。该引用包含通道标识符和安全关键平台特定属性，例如固件版本，以及指示是否启用抢占和调试的标志。报价使用 AK 签名。设备驱动程序将此引用和 AK 证书（在初始化期间获得）传递给用户空间运行时。运行时通过以下方式对响应进行身份验证：(a) 验证 AK 证书，(b) 使用证书中嵌入的公共 AK 验证报价，以及 © 检查报价中的公钥是否与 UK pub 匹配。然后，运行时可以解密 CEK 并使用它来加密发送到 GPU 的所有命令。

建立会话后，命令处理器将使用 CEK 验证并解密其通过通道接收的所有命令。这保证了只有拥有 CEK 的用户才能执行访问上下文地址空间的任务。我们使用经过身份验证的加密（GCM 模式下的 AES）和每通道计数器作为 IV 来保护命令免受丢弃、重放和重新排序攻击。这确保了 GPU 运行时生成的所有命令都被传递到命令处理器而不被篡改。

Secure Context Isolation

在现有的 GPU 中，管理资源（例如设备内存）的责任在于设备驱动程序。例如，为应用程序对象分配内存时，驱动程序确定分配对象的虚拟地址，然后确定要映射到虚拟页的物理页，最后通过 MMIO 更新通道页表中的虚拟物理映射。这种机制创造了一个巨大的攻击向量。受损的驱动程序很容易违反通道级隔离，例如，通过将受害者的页面映射到恶意通道的地址空间。

防止此类攻击并实现隔离的一种方法是在通道之间静态划分硬件资源。然而，这将导致资源利用不足。此外，它禁止通道之间低成本的资源共享，而这是实现流等功能所必需的。相反，Graviton 通过对硬件资源施加严格的所有权规则来保证隔离，同时允许驱动程序动态分区资源。

更正式地，考虑映射到与安全上下文C和通道加密密钥CEK相关联的安全通道并且包含敏感数据的物理页P。我们认为应用程序在安全上下文中分配的任何对象（代码和数据）以及所有通道的所有地址空间管理结构（即通道描述符、页目录和页表）都是敏感的。我们建议对 GPU 进行硬件更改，以强制执行以下不变量，这些不变量一起意味着隔离。

在本节的其余部分中，我们将描述用于强制执行这些不变量的硬件扩展，并讨论它们对驱动程序-GPU 接口的影响。

Memory regions.

我们的第一个扩展是将设备内存分为三个区域：不受保护、受保护和隐藏，每个区域都有不同的访问权限。

未受保护区域是内存中的一个区域，主机可以通过 PCI BAR 寄存器看到并访问该区域。驱动程序可以使用此区域来分配通过 MMIO 访问的非敏感内存对象（例如，同步和中断缓冲区）。该区域也可以从 GPU 引擎访问。

受保护区域对主机可见，但无法访问。驱动程序可以在区域内分配对象（通过创建页面映射），但无法直接通过 MMIO 访问该区域。因此，该区域只能从 GPU 引擎访问。

隐藏区域对主机 CPU 或 GPU 引擎不可见或不可访问。该区域中的内存无法通过 PCI 访问，并且不会映射到任何通道的虚拟地址空间。该区域专门保留供命令处理器使用，用于维护元数据，例如受保护内存页的所有权状态和每通道加密密钥。

区域可以通过对 PCI 控制器中的 MMIO 访问和更新命令处理器中的地址空间管理结构的命令进行简单的范围检查来实现。每个区域的大小可以在初始化期间由不受信任的主机软件配置。大小不影响安全；只有系统管理员的可用性才能通过分配一个小的受保护区域来阻止安全上下文的创建。

Address-space management

下一组扩展旨在强制执行 Invariant 5.1 和 Invariant 5.2。我们通过将分配和释放虚拟和物理内存的任务与管理设备内存驻留地址转换数据结构（即页目录和页表）的任务分离并将后者委托给 GPU 的命令处理器来实现这一目标。特别是，我们允许驱动程序决定对象将驻留在虚拟内存和物理内存中的位置，但要求驱动程序使用图 6 中描述的 API 通过命令处理器路由更新页目录和页表的请求。

命令处理器中 API 的实现通过跟踪所有权来强制执行这些不变量受保护区域中的物理页位于称为受保护内存元数据 (PMM) 的数据结构中。我们首先描述PMM，然后描述命令。

Tracking ownership

PMM 是位于隐藏内存中的数据结构，对于主机来说是不可见的。它使用内存页的物理地址进行索引。页面以小页面（即 4 KB）的粒度进行跟踪。 PMM 为每个物理页维护以下属性。

• 属性owner_id 是拥有该页面的频道的标识符。
• 属性 state ∈{FREE，MAPPED} 表示页面是否空闲或者已经映射到某个频道。初始值是免费的。
• 属性 refcnt 跟踪物理页已映射到的通道数。
• 属性lock ∈ {UNLOCKED, LOCKED}表示页面是否需要显式授权才能取消映射。
• 属性pgd_index是页目录中的索引，它指向包含当前页映射的页表。使用此属性，命令处理器可以重建物理页的虚拟地址。从这个意义上说，PMM充当受保护区域的倒排页表，即存储 PA → VA 映射。
• 属性 pgt_entrycnt 是一个 2 字节值，用于跟踪页表内分配的页表条目的数量。使用此属性，命令处理器可以知道锁定页表是否为空并因此可以取消映射。

假设每个 PMM 条目需要 64 位，则具有 6GB 物理内存的 GPU 的 PMM 总大小为 12MB，约为总内存的 0.2%。

Commands

用于上下文和地址空间管理的新命令使用 PMM 来强制执行 Invariant 5.1 和 Invariant 5.2，如下所示：

CH_CREATE

该命令将新创建的通道 chid 的页目录地址（pgd_address）作为参数。它检查通道描述符和页目录是否分配在受保护区域的页上，以及这些页是否空闲。前一个约束确保在通道创建后，驱动程序不会绕过 API 并直接通过 MMIO 访问通道描述符和页面目录。

如果检查成功，页面将变为 MAPPED，并且页面的owner_id 属性将更新为正在创建的通道的标识符。如果正在创建安全通道（使用公钥），则页面将被LOCKED。然后命令处理器更新通道描述符中页面目录的地址，并清除存储页面目录的页面内容以防止攻击者注入过时的翻译。如果包含通道描述符或页目录的任何页面已LOCKED或MAPPED到现有通道，则 CH_CREATE 将失败。

CH_PDE

此命令取消映射现有页表（如果存在），并在通道页目录中的索引 pgd_index 处映射新页表。

在取消映射之前，该命令检查页表的物理页是否已UNLOCKED或 pgt_entrycnt 属性是否为零。无论哪种情况，该命令都会减少 refcnt。如果 refcnt 达到零，则页面变为FREE。如果驱动程序尝试取消映射 LOCKED 页表或具有有效条目的页表，该命令将失败。

在映射新页表之前，该命令检查页表是否分配在受保护区域中的FREE页上。如果检查成功，页面将变为 MAPPED。此外，如果通道是安全的，页面就会被LOCKED。但是，如果这些页面已经 MAPPED，则该命令会通过比较相应的公钥哈希来检查拥有该页面的通道（当前owner_id）和页表映射到的通道是否属于同一上下文。如果哈希值匹配，则页面的引用计数会增加。这允许物理页表和物理页在通道之间共享，只要它们共享相同的上下文；这是支持 CUDA 流等功能所必需的 [31]。如果任一检查成功，该命令将在页目录中创建一个新条目并清除存储页表的页内容。如果页表映射到与不同上下文关联的通道，则该命令失败。

CH_PTE

此命令删除现有映射并为从 VA 开始的大小为 size 的虚拟地址的连续范围创建新映射（由 PTE指定），其中 VA 是通道 chid 的页目录中索引 pgd_index 处的页表在索引 pgt_index 处映射的虚拟地址。在清除现有页表条目之前，该命令会检查物理页是否已LOCKED。要删除LOCKED物理页的映射，该命令需要用户运行时以 MAC 的形式通过元组 {chid,VA, size} 使用 CEK 和每通道计数器作为初始化向量 (IV) 进行显式授权。 MAC 的不可伪造性与 IV 计数器的使用相结合，确保恶意驱动程序无法伪造取消映射分配给安全通道的物理页面，然后将其重新映射到其他通道的命令。如果检查和 MAC 验证成功，页面将转换为 FREE，并且页表条目将被清除。

同样，在创建新映射之前，该命令会检查页面是否FREE。此外，如果通道是安全的，该命令会检查页面是否位于受保护区域（对于敏感代码和数据，第 6 节中讨论）。如果检查成功，该页面将变为 MAPPED，如果该页面正在映射到安全通道，则该页面将变为 LOCKED。[请注意，CH_PTE 还允许将未受保护区域中的页面映射到安全通道；这些页面可以通过 MMIO 访问，并用于存储对象，例如驱动程序同步所需的栅栏缓冲区。]如果页面已被 MAPPED，该命令将检查拥有该页面的通道（当前owner_id）和通过比较相应的公钥哈希值，页面映射到的通道属于同一上下文。成功后，该命令会增加页表的 pgt_entrycnt，更新页表，并发出 TLB 刷新以删除任何过时的转换。虽然传统上后者是设备驱动程序的责任，但在我们的设计中，刷新是隐式的。如果任何页面映射到与不同上下文关联的通道，则该命令将失败。

当命令成功时，它会生成一个摘要结构，该结构对在调用 CH_PTE 期间创建的所有 VA → PA 映射进行编码。摘要是一个元组 {chid,VA, n, k, HASH(p_1, …, p_n)}，其中 VA 是正在分配的内存的起始虚拟地址，n 是受保护的内存中分配的页数区域，k是分配的总页数，p_1,…p_n 是受保护的物理页的地址。命令处理器还使用 CEK 在此摘要上生成密钥 MAC。如下所述，运行时使用此摘要来验证敏感代码和数据是否分配在受保护区域中。

CH_DESTROY

此命令通过遍历页目录、查找通道拥有的物理页并重置其PMM中entries来释放分配给通道的内存。然后，它取消映射通道描述符和页目录的物理页，减少用于页表的页的 refcnt，如果它们的 refcnt 减少到 0，则页将变为 FREE。

对于安全通道，该命令需要使用 CEK 和每通道计数器作为 IV 以 MAC over chid 的形式进行显式授权。然而，命令处理器也接受该命令的未经授权的实例；这使得设备驱动程序能够在用户运行时不再能够发出授权命令的情况下回收资源（例如，由于进程崩溃）。

在这种情况下，命令处理器会遍历 PMM 来查找专门映射到通道地址空间的物理页，取消映射它们，递减它们的 refcnt，如果它们的 refcnt 减少到 0，则清除它们的内容。命令处理器还会刷新所有缓存，因为内存访问命令处理器不遍历计算引擎的内存层次结构。

恶意驱动程序可能会滥用此机制来回收仍在使用的通道资源，从而导致拒绝服务；当包含敏感信息（包括通道描述符）的页面被擦除时，不会违反机密性或完整性。

CH_MEASURE

我们使用命令 CH_MEASURE 来扩展命令处理器，以生成总结安全通道内容的可验证工件。该工件可用于向挑战者（例如 GPU 运行时）证明通道在保证通道隔离的硬件上处于某种状态。在我们的实现中，CH_MEASURE 将应包含在测量中的一系列虚拟页面作为参数。它生成一个测量，其中包含请求范围内页面内容的摘要 (HMAC) 以及使用 CEK 的测量的密钥 MAC。

Bootstrapping

引入基于命令的 API 进行地址空间管理会引发以下问题：驱动程序如何发送命令来管理安全通道的地址空间，而无需访问特定于通道的 CEK？我们通过要求驱动程序使用单独的通道（我们称之为引导通道）来为所有其他通道路由地址空间管理命令来克服这个问题。我们允许驱动程序通过 MMIO 创建和配置一个或多个引导通道，并在未受保护的区域中分配其地址空间管理结构。

命令处理器通过拦截对通道控制区域中的通道描述符属性的 MMIO 写入来将通道识别为引导通道。如果写入该属性的地址位于未受保护的区域中，则相应的通道将被标记为引导通道。

为了确保驱动程序不会使用引导通道来破坏安全通道的隔离，命令处理器禁止引导通道向复制和计算引擎发出命令，因为此类命令可用于访问敏感状态。命令处理器还检查从引导通道执行的所有命令是否用于配置非引导通道。这可以防止对手将安全上下文的受保护内存页分配为引导通道的页目录和/或页表，然后利用 CH_PDE 和 CH_PTE 命令来篡改安全上下文的内存。

Big page support

现代 GPU 上的虚拟内存子系统采用多种页面大小。例如，在 NVIDIA GPU 中，每个页目录条目由两个条目组成，一个指向小页 (4KB) 表，另一个指向大页 (128KB) 表。我们的设计需要较小的扩展来支持大页面。在PMM中，我们继续以小页面粒度跟踪页面元数据，但我们向每个条目添加一位以指示相应的物理页面是否映射到小或大虚拟页面。此外，我们需要在 CH_PDE 和 CH_PTE 命令中添加一个附加参数来指定更新是针对小页表还是大页表。最后，这些命令检查同一虚拟页是否未映射到两个不同的物理页。

Error handling

当命令失败时，命令处理器将错误写入 SRAM 寄存器中，设备驱动程序可通过 MMIO 访问该寄存器。这允许设备驱动程序采取必要的操作，以保证命令处理器和设备驱动程序之间通道地址空间的一致视图。

Software Stack

我们现在描述 Graviton 运行时支持的新 CUDA 原语，它们使用安全上下文并支持具有强大安全属性的应用程序设计。

Secure memory management

Graviton 运行时支持两个原语 cudaSecureMalloc 和 cudaSecureFree，用于在受保护区域中分配和释放设备内存。

cudaSecureMalloc 保证分配的 GPU 内存归当前上下文所有（Invariant 5.1），并且位于受保护区域内（Invariant 5.3）。与 cudaMalloc 的实现非常相似，cudaSecureMalloc 依赖设备驱动程序来识别设备内存中未使用的虚拟内存和物理页，并使用命令 CH_PDE 和 CH_PTE 更新页目录和页表。如上所述，这些命令实施检查以强制执行 Invariant 5.1。运行时使用以下方法强制执行 Invariant 5.3由 CH PTE 命令生成的摘要结构。特别是，运行时使用 CEK 和通道特定计数器来验证驱动程序返回的摘要结构。如果分配跨越多个页表，驱动程序可能会返回多个摘要结构。身份验证后，运行时可以使用摘要中的属性 n 来验证内存对象是否分配在受保护区域中。

cudaSecureFree 首先使用 memset 内核清除所有分配的页面。然后，它使用 CEK 在对象的起始虚拟地址和大小上生成 MAC，并将 MAC 传递给驱动程序，驱动程序生成 CH PTE 命令以从页表中删除条目。 MAC 用作从页表中删除条目的授权（不变式 5.2）。在对象跨越多个页表的情况下，运行时为每个页表生成一个 MAC。

驱动程序和硬件之间重新定义的接口意味着驱动程序无法压缩分配给安全通道的页面。按照惯例，驱动程序负责压缩活动对象并减少物理地址空间中的碎片。然而，Graviton 禁止驱动程序访问这些对象。这可能会导致受保护区域出现碎片。我们将硬件支持留给未来的压缩工作。

Secure memory copy

Graviton 运行时支持原始 cudaSecureMemcpy，用于将代码和数据从主机 TEE 安全地复制到设备内存，反之亦然。该协议（图 7）的工作原理如下。

1. 创建安全上下文后，运行时使用 cudaSecureMalloc 分配设备内存，并将执行身份验证解密（以明文形式）的内核复制到分配的内存中，称为 AuthDec。为了确保正确复制内核而不被篡改，运行时会测量设备内存中包含内核的区域（使用 CH MEASURE），并检查返回的摘要是否与主机 TEE 内计算的内核摘要相匹配。
2. cudaSecureMemcpy 的实现首先使用主机 TEE 内的新对称密钥对要复制的数据进行加密，并将加密的数据复制到不可信内存。
3. runtime 启动 DMA 将加密数据传输到目标内存区域。启动 DMA 的命令组使用 CEK 进行加密和完整性保护。
4. runtime 使用 AuthDec 内核来解密设备内存中的数据。它发出一个命令组来启动内核，传递数据的虚拟地址、数据加密密钥和预期的身份验证标签作为内核的参数。
5. AuthDec 对加密数据进行身份验证并生成一个身份验证标签，该标签会根据预期的身份验证标签进行检查。如果检查成功，内核将解密设备内存中的数据，覆盖进程中的加密数据。

安全内存复制的一个关键属性是加密敏捷性。由于原语完全以软件实现，因此运行时可以支持各种加密和认证方案，而无需更改硬件。

Secure kernel launch

cudaSecureKernelLaunch 使用安全内存复制将内核的代码和常量内存传输到 GPU，然后发出命令组来启动内核。

最近的 GPU 在指令和/或线程块边界引入了抢占。扩展我们的设计以支持线程块边界的抢占相对简单，因为线程块是独立的计算单元[42]，并且所有短暂状态（例如寄存器、应用程序管理的内存、缓存和 TLB）都可以在抢占时刷新。还可以通过在为每个通道保留的隐藏存储器的一部分中保存和恢复临时状态来支持指令级抢占。

Secure streams

CUDA 流是用于重叠主机和 GPU 计算以及 I/O 传输的原语。每个流都分配有一个单独的通道，每个通道共享相同的地址空间，以实现独立任务的并发和异步提交。我们的设计通过允许同一上下文中的通道共享页表和页面来支持安全流（cudaSecureStreamCreate）。特别是，运行时可以将内存对象重新映射到流的地址空间。与分配请求非常相似，驱动程序使用 CH_PTE 命令来更新页表。运行时验证 CH_PTE 命令生成的 HASH(p_1, …, p_n) 是否与请求的内存对象的哈希匹配。

Evaluation

Implementation

我们使用开源 GPU 堆栈实现了 Graviton，该堆栈由 ocelot（CUDA 运行时 API 的实现 [14]）、gdev（实现 CUDA 驱动程序 API [21]）以及 libdrm 和 nouveau（实现用户和内核）组成。空间GPU设备驱动程序[29]。由于 gdev 的限制（例如，无法使用纹理），我们无法使用 cuBLAS（NVIDIA 线性代数库）中的某些运算，例如矩阵-矩阵 (GEMM) 和矩阵-向量乘法 (GEMV)。相反，我们使用了 Magma 的实现，这是一种具有竞争性能的 cuBLAS 开源实现 [43]。我们的实现尚未使用 SGX 来托管用户应用程序和 GPU 运行时 - 将堆栈移植到 SGX 可以使用 SGX 特定的容器来实现 [5,39,44]，这超出了本工作的范围。

Command-based API emulation

由于现代 GPU 中的命令处理器不可编程，因此我们在软件中模拟建议的命令。我们的模拟器由（a）一个runtime 组件组成，它将每个新命令及其参数转换为一系列现有命令，在执行期间触发中断；（b）一个内核组件，它处理中断，在中断处理程序中重建原始命令，并实现命令的语义。仿真器使用以下命令：REFCNT 设置可从主机读取的通道控制区域中的 32 位寄存器的值，SERIALIZE 等待直到执行先前的命令，NOP 和 NOTIFY 在后续 NOP 命令完成时触发中断。

图 8 显示了仿真器的伪代码以及 CH CREATE 命令的示例。当提交命令时，运行时会调用函数 cmd emu，它将命令的原始位流中的每个 32 位值 v 转换为以下命令序列：以 v 作为参数的 REFCNT、SERIALIZE、NOTIFY 和 NOP。该序列被推入环形缓冲区（使用push_ring_emu），命令处理器从那里读取它。当命令处理器执行这个序列时，它会引发一个中断，并在主机上调用一个中断处理程序（interrupt_handler）。处理程序实现一个状态机，该状态机读取通道控制区域中的寄存器并一次重建原始命令一个值。重建整个命令后，模拟器通过 MMIO（图中未显示）对设备内存进行读写来实现其语义（在本例中使用 chcreate_emu）。

我们选择这种仿真策略是因为它允许我们运行软件堆栈就像我们有硬件支持一样。此外，它为我们提供了保守的性能近似值，因为每个命令处理器对设备内存中 PMM 和内存映射数据结构的访问都会转化为通过 PCIe 从主机到设备内存的访问。

Command group authentication emulation

我们还模拟命令处理器逻辑，以对命令组进行身份验证解密。我们的模拟器会在加密的命令组被复制到设备内存解密之前拦截它们并解密它们。正如我们稍后展示的，这为我们提供了保守的性能近似值，因为我们在软件（由 AES-NI 辅助）而不是硬件加密引擎中解密命令组。

为了估计使用硬件加密引擎可以实现的性能，我们在模拟器中添加了一种模式，该模式对主机上的命令组进行加密，但以明文形式将命令组发送到设备，并添加与解密命令的延迟相等的延迟组使用硬件引擎。我们使用已发布的硬件 [40] 中解密块的延迟和命令组的大小（以块为单位）来计算解密延迟。

Secure memory copy

我们的安全内存复制实现结合了 AES 和 SHA-3 以进行身份​​验证加密。我们选择 SHA-3，因为其基于并行树的哈希方案非常适合 GPU。它还提供配置方法（例如轮数），允许开发人员探索不同的性能与安全权衡 [6, 7]。

Performance Overheads

Testbed setup

在评估中，我们使用了运行频率为 3.5 GHz 的 8 核 Intel Xeon E5-1620-v3 服务器和两种不同的 NVIDIA GPU：运行频率为 863 MHz 的具有 2304 个 CUDA 内核的 GTX 780 和运行频率为 889 MHz 的具有 2880 个 CUDA 内核的 GTX Titan Black兆赫。两种 GPU 的总体性能趋势相似。因此，我们仅提供Titan Black 的结果。主机CPU运行Linux内核4.11，并使用CUDA工具包v5.0进行GPU内核编译。

Command-based API

首先，我们使用矩阵矩阵加法微基准来量化使用基于命令的 API 的开销。表 1 将命令执行延迟细分为五个部分： Base，是在没有任何安全扩展的情况下命令执行期间执行的所有 MMIO 操作的累积延迟；Inv, 这是包括 PMM 维护在内的不变检查的额外延迟； Init, 是页目录和页表初始化的延迟；Crypto，包括所有必需的加密操作；和中断处理，标记为 Intr。请注意，测量的延迟是基于仿真获得的，因此高估了通过专用硬件支持可以实现的延迟。

我们发现CH_CREATE的延迟主要由初始化页目录的成本决定，而CH_DESTROY的延迟则由遍历页目录以从PMM中删除锁定页表的页面的成本决定。对于 CH_PDE，我们测量为小页表和大页表分配页目录条目的延迟。为小页表分配一个条目会产生更高的延迟，因为该命令需要重置大量条目。最后，我们测量了 CH_PTE 分配跨越小页表或大页表八个条目的对象的延迟。在这里，大页表的延迟较高，因为使用 PMM 进行大量不变检查，PMM 以小页粒度跟踪所有权。

Secure memory copy

图 9 绘制了三种 AES/SHA3 变体和传输大小的安全复制延迟。变体 ParallelHash256 和 Marsupilami14 提供 256 位哈希强度，而 Kangaroo12 提供 128 位哈希强度。我们发现，对于较小的传输大小，延迟保持平坦，对于较大的传输大小，延迟几乎呈线性扩展。除非另有说明，我们使用 AES256/Marsupilami14 配置进行其余的评估。

表 2 显示了 AES256/Marsupilami14 配置的延迟细目。 Base是指正常（不安全）复制的延迟，其他四个组件是指在CPU和GPU上执行AES和SHA-3的延迟。我们发现，随着传输大小的增加，SHA3-CPU 和 AES-GPU 占据了大部分开销（64MB 传输的延迟超过 75%）。对于小数据量，受计算限制的 AES-GPU 阶段未充分利用 GPU 核心，因此执行时间保持平稳。相比之下，SHA3-GPU 内核由于算法复杂性较低，因此可扩展性更好。更一般地，我们将两者归因于这些成本是由于 ISA 缺乏对 CPU 上的 SHA-3 和 GPU 上的 AES 的支持。

CUDA driver API

我们对 CUDA 运行时 API 的安全扩展的实现基于对 CUDA 驱动程序 API 的扩展。表 3 显示了增加安全性对这些 API 延迟的影响。正如预期的那样，所有驱动程序 API 都会产生较高的延迟。上下文创建安全版本 cuCtxCreate 的相对较高延迟主要是创建 RSA 密钥的延迟（延迟的 75%）。模块加载 cuModuleLoad 的安全版本更昂贵，因为它 (a) 引导安全复制，测量经过身份验证的加密内核，以及 (b) 使用安全复制将应用程序内核传输到设备内存。这些 API 通常不经常使用，因此这些延迟不会对大多数应用程序的整体执行时间产生很大影响。另一方面，cuMemAlloc 和 cuMemFree 可能位于使用大量短期对象的应用程序的关键路径上。这些操作的延迟增加主要是由于仿真（中断和 MMIO 访问）造成的。我们预计这些操作在真正的 Graviton 硬件上的实际实现会产生更低的开销，并且不涉及中断并减少内存访问延迟。

Applications

最后，我们使用一组 GPU 基准测试来量化使用安全 CUDA API 对端到端应用程序性能的影响。我们使用两个具有不同特性的基准测试，即 Caffe，一个用于人工神经网络的训练和推理 [18]，以及 BlackScholes，一种期权定价应用程序 [8]。

Cifar-10

我们使用 Caffe 在 Cifar-10 数据集上训练卷积神经网络，该数据集由跨越 10 个类别的 60000 张 32x32 图像组成。该网络由 11 层组成：3 层卷积层、池化层、修正线性单元非线性 (RELU) 层，然后是局部对比度归一化层和线性分类器。我们运行 40 个 epoch（每个 epoch 扫描 50000 张图像），批量大小为 200，并在每个 epoch 结束时使用 10000 张图像，批量大小为 400 来测试模型。基线系统和 Graviton 都实现了相同的训练准确性。

图 10 显示了 Graviton 对三个执行阶段的执行时间的影响，即初始化、测试（类似于推理）和训练。对于训练，报告了所有 epoch 中 25 个批次的平均执行时间。我们还将开销分为两个部分：隔离（即使用安全 CUDA 驱动程序 API 和命令组身份验证）和安全内存复制。在模拟环境中，我们的安全扩展在每个阶段分别导致速度下降 73%、57% 和 53%。

初始化期间的开销是由于安全上下文和模块创建（占开销的 22%）、用于初始测试的模型和数据的安全副本（31%）以及初始测试阶段期间的命令身份验证（47%）而产生的。

测试和训练开销的细分显示，命令组身份验证分别占开销的 66% 和 77%。这是因为此工作负载执行大量相对较短的内核（每个批次和层一个）。我们分析了内核启动所花费的时间，发现很大一部分开销是由于模拟命令的经过身份验证的解密的成本造成的。特别是，每次安全内核启动都会产生 9.2μs 的延迟，其中运行时加密延迟 0.8μs，模拟器解密延迟 3.0μs。

该图还显示了假设我们使用硬件加密引擎扩展命令处理器的估计开销。由于身份验证解密时间从 3μs 减少到约 30ns，测试和训练阶段的开销从 35-41% 减少到 5-7%。添加硬件加密引擎可将总体开销降低至 17%（图 11）。

MNIST

我们使用 Caffe 在 MNIST 数据集上训练自动编码器，该数据集由 60000 个 28x28 手写数字组成。该网络由六个编码层和六个解码层组成。我们运行 10000 个批次（批次大小为 128），并使用 8192 个图像（批次大小为 256）每 500 个批次测试模型。基线和 Graviton 都达到相同的精度。

如图 11 所示，Graviton 引入了 33% 的性能开销。由于编码和解码层的复杂性低于卷积层，因此开销比 Cifar10 更高，因此每次迭代在安全内存复制上花费更多的时间。

BlackScholes

我们运行 BlackScholes，共 10 批，每批 400 万个选项，每批 2500 次迭代。如图 11 所示，总体开销为 26%。与 Cifar-10 不同，命令身份验证不是 BlackScholes 中的一个因素，因为它每批执行一个长时间运行的内核；因此，强制隔离的开销主要归因于安全上下文和模块创建。

Related Work

Trusted hardware

在将代码和数据与系统的其余部分隔离的可信硬件上存在工作历史 [9,13,15,17,24,27,32,41,48]。 Intel SGX [28] 是这一领域的最新成果，但之所以脱颖而出，是因为它提供了全面的保护，并且已经在客户端 CPU 和公共云平台中可用。 Graviton有效地将CPU上TEE的信任边界扩展到丰富的设备，例如GPU。

Trusted execution on GPUs

许多研究人员已经确定需要一种机制，允许托管在 TEE 中的应用程序通过可信路径与 I/O 设备安全地进行通信。于等人。 [51]提出了一种使用 GPU 可信路径方法的方法。他们的方法依赖于特权主机组件来强制虚拟机和显示之间的隔离，而我们的攻击者模型则排除了对任何主机组件的信任。

PixelVault 提出了一种将加密操作安全卸载到 GPU 的架构 [46]。随后的工作表明，由于分配和模块创建时缺乏页面初始化、缺乏内核级隔离以及通过将调试器附加到正在运行的内核（和 GPU 运行时）而导致寄存器信息泄漏，此类设计存在安全漏洞。或在同一通道上调用内核 [23, 52]。相比之下，Graviton 在 GPU 上实现了通用的可信执行环境。由于用户将 GPU 运行时托管在 CPU TEE 内，因此可以防止通过内核调试泄漏信息，从而保证在执行期间无法启用调试。

Conclusion

与最新的 CPU 不同，GPU 不提供对可信执行环境 (TEE) 的支持，从而在安全性和性能之间进行权衡。在本文中，我们介绍了 Graviton，一种在 GPU 上支持 TEE 的架构。我们对 NVIDIA GPU 的概念验证表明，所提出的架构的硬件复杂性和性能开销都很低。

未来工作的一个有趣途径是扩展 Graviton 以确保跨多个 GPU 的内核执行和通信的安全，并研究对高级功能的支持，例如按需分页和动态线程创建。此外，我们还想研究是否可以消除对 CPU TEE（例如 Intel SGX）的依赖，如果可以的话，我们可以量化对系统性能的影响。最后，我们想验证所提出的架构是否可以扩展到其他加速器，例如 FPGA。

这篇关于【论文分享】Graviton: Trusted Execution Environments on GPUs 2018’OSDI的文章就介绍到这儿，希望我们推荐的文章对编程师们有所帮助！

---