【论文分享】Heterogeneous Isolated Execution for Commodity GPUs 2019‘ASPLOS

Heterogeneous Isolated Execution for Commodity GPUs 2019’ASPLOS

Abstract

传统CPU和基于它们的云系统已经采用了基于硬件的可信执行环境，以安全地将计算与恶意操作系统或硬件攻击隔离开来。然而，GPU 及其云部署尚未包括对基于硬件的可信计算的支持。随着云环境中大量敏感数据被卸载到GPU加速，确保数据的安全是当前迫切的需求。目前部署的外包 GPU 模型很容易受到受损特权软件的攻击。为了即使在易受攻击的操作系统下也支持 GPU 上的隔离远程执行，本文提出了一种新颖的硬件和软件架构，称为 HIX（异构隔离执行）。 HIX 不需要修改 GPU 架构来提供保护：相反，它通过修改 CPU 和 GPU 之间的 I/O 互连以及重构 GPU 设备驱动程序以在 CPU 可信环境中工作来提供安全性。 HIX 背后的架构选择的结果是，该概念可以应用于 GPU 之外的其他卸载加速器。这项工作在具有 KVM 和 QEMU 的模拟机上实现了建议的 HIX 架构。使用真实 GPU 模拟安全支持的实验结果表明，Rodinia 基准测试的安全性能开销平均减少至 26%，同时提供安全的隔离 GPU 计算。

Introduction

在传统的基于CPU的计算中，基于硬件的可信执行环境（TEE）（例如Intel SGX和ARM TrustZone）一直为用户应用程序提供可信且隔离的计算环境。这种基于硬件的 TEE 减少了对 TEE 中运行的处理器和关键代码的计算的可信计算基础 (TCB)。借助 TEE 支持，可以保护安全关键型应用程序免受受损的特权软件以及对内存和系统总线的基于硬件的攻击，从而提供在不受信任的远程云服务器上运行的安全计算。

随着从传统高性能计算到数据中心加速和机器学习应用，通用 GPU 计算的使用越来越多，确保 GPU 计算的安全已成为保护安全敏感数据的关键[34,45,56,57]。然而，尽管越来越多的关键数据在GPU中处理，但GPU计算尚未支持可信计算。在当前的系统架构中，高性能离散GPU通过I/O互连（例如PCI Express（PCIe）总线）与CPU进行通信，并且作为操作系统一部分的GPU驱动程序控制GPU [25]。由于特权操作系统可以完全控制硬件I/O互连和GPU驱动程序，GPU中的计算很容易受到操作系统的潜在攻击[8]。除了基于 GPU 的计算之外，各种基于加速器的计算模型也在不断增加易受攻击的特权软件下对加速器的更高级别安全支持的需求。

在现有架构中，GPU 中的代码和数据都可能受到特权对手的破坏。最近的工作表明，可以通过使用现成的逆向工程工具在运行时破坏和替换代码来破坏 GPU 代码的完整性 [13]。除了代码之外，GPU 中的数据也可能被揭露和泄露 [45]。容易受到机密性攻击的GPU数据包括传入和传出GPU的通信数据以及在GPU内处理的数据。 GPU 容易受到机密性和完整性攻击的原因在于缺乏对其接口（例如 I/O 互连和内存映射 I/O 地址）的访问控制。

为了支持 GPU 中的安全计算，本文提出了一种新颖的硬件和软件架构，用于将 GPU 与潜在的恶意特权软件（操作系统和虚拟机管理程序）隔离。所提出的架构称为异构隔离执行 (HIX)，需要对当前 PCIe 互连实现和 CPU 中的 TEE 支持进行少量扩展。 HIX的目标是将TEE技术的安全保证（即用户数据的机密性和完整性）扩展到异构计算环境。截至撰写本文时，这些技术都无法保护异构系统中的加速器免受特权软件攻击。它们仅保护处理器上运行的受信任“飞地”中的代码和数据。在这项工作中，我们扩展了广泛使用的可信隔离技术 Intel SGX 的范围，以保护通用加速器，特别是 GPU。

我们提出的架构由四个主要的硬件和软件更改组成。首先，GPU 驱动程序的关键功能从操作系统 (OS) 中删除，并重新定位到其自己的 GPU enclave 中的单独进程中。 GPU enclave 是当前 SGX enclave 的扩展，旨在专门管理 GPU。其次，对 PCIe 互连架构进行了轻微修改，以防止操作系统在 GPU enclave 完全初始化后更改互连的路由配置。第三，增强了内存管理单元 (MMU)，以保护内存映射的 GPU I/O 区域免遭未经授权的访问。第四，GPU应用程序的CPU对应进程在SGX enclave上运行，并且SGX enclave建立了到GPU enclave的可信通信路径，即使针对特权对手，该路径也很稳健。

为了在不进行任何 GPU 修改的情况下支持 GPU 的安全执行环境，HIX 不提供针对直接基于硬件的攻击的保护，因为在当前架构中 PCIe 总线和 GPU 内存容易受到此类硬件攻击。虽然与 CPU 的硬件 TEE 相比，安全级别较低，但 HIX 可以扩展到其他加速器，而不需要任何硬件如果加速器通过 I/O 互连连接，则修改加速器本身。

我们从安全性和性能方面评估所提出的架构。我们在 KVM 和 QEMU 上实现了 HIX 原型，为 GPU enclave 添加了额外的指令，并将 GPU 驱动程序与操作系统分离。使用连接到真实 GPU 的仿真的原型表明，对于 Rodinia 套件的基准测试，与传统的不安全 GPU 计算相比，HIX 安全 GPU 计算带来的性能下降为 26%。

Contributions

我们提供 GPU 计算的攻击面评估。我们确定了可能受到特权软件攻击的关键 GPU 组件：PCIe 互连、内存映射 I/O 区域和 GPU 驱动程序。

我们增强了PCIe 互连的设计，以阻止GPU 初始化后的任何路由更改，并进一步保证内存映射I/O 区域到GPU 的地址映射不变性。

我们扩展了当前的SGX 接口以支持GPU enclave，它以安全的方式运行GPU 驱动程序。 MMU 设计经过扩展，可保护 GPU 内存映射 I/O 区域免遭未经授权的访问。

我们在带有KVM 和QEMU 的仿真系统上实现了原型，以评估HIX 的性能开销。尽管由于硬件需要发生变化而在仿真系统中实现，但它忠实地反映了硬件接口和软件架构的必要变化。

Background

HIX 是在 Intel SGX 架构和 PCI Express 标准之上设计的。我们在本节中简要概述这些技术。

Intel Software Guard Extensions (SGX)

英特尔 SGX 是一种基于硬件的保护技术，可提供称为 enclave 的可信执行环境 (TEE)，甚至可以免受特权软件和直接硬件攻击。 SGX 保护 enclave 内存和执行上下文以支持强隔离执行。增强了 SGX 基于硬件的隔离执行通过验证 enclave 上运行的代码完整性的证明服务 [1, 35]。

在 SGX 威胁模型下，主内存是不可信的，因此，SGX 提供内存加密和访问限制机制来保护 enclave 的一小块主内存区域，称为 enclave 页缓存 (EPC)。尽管SGX使用不受信任的操作系统提供的虚拟内存支持，但它通过基于硬件的验证来保护EPC页面免受未经授权的访问。

图 1 说明了 SGX 地址空间的结构。图中，ELRANGE（Enclave Linear Address Range）是Enclave中受保护的虚拟地址范围，该范围内的页面保证映射到EPC页面。创建 enclave 时，系统软件使用 EADD SGX 指令将页面的虚拟地址和相应的 EPC 物理地址注册到受保护的内存中。在处理 EADD 指令期间，硬件将映射信息存储在安全区页面缓存映射 (EPCM) 中，以验证 MMU 中地址转换期间未来对该页面的访问[9]。

PCI Express Architecture

现代 GPU 通过 PCI Express (PCIe) 接口连接到系统。 PCIe 接口有助于内存映射 I/O (MMIO) 对 PCIe 设备的软件访问。由于MMIO机制将设备的硬件寄存器和内存映射到软件的系统内存地址空间，这使得软件可以使用常规内存地址透明地访问PCIe设备。

图2说明了系统如何使用系统内存地址映射将设备访问请求路由到设备[49]。 CPU 负责区分对 MMIO 区域的访问和对主内存的访问。它使用在系统启动时由 BIOS 初始化的内部硬件寄存器来适当路由 MMIO 的访问请求 [19]。

当内存访问的地址针对 MMIO 区域时，PCIe root complex将接收该请求。由于 PCIe 设备作为tree连接到系统，其中 PCIe root complex是其root，root complex创建 PCIe 事务数据包并使用硬件路由寄存器将其路由到所需设备 [5, 43]。这些寄存器也会在系统启动时由 BIOS 进行初始化，以覆盖所连接设备的整个物理地址范围。

现代 PCIe 设备使用直接内存访问 (DMA) 直接读取或写入主内存，无需 CPU 干预。图 2 中的 DMA 箭头显示了如何系统路由 DMA 请求。输入/输出内存管理单元（IOMMU）可用于将设备地址转换为 DMA 的物理地址[42]。

Threat Model

Attacker Model and Assumptions

我们解决的对抗模型是一个特权对手，其目标是破坏 GPU 处理的数据的机密性和完整性。我们重点关注由用户应用程序到 GPU 之间的硬件和软件 I/O 数据路径组成的攻击向量。我们假设对手拥有对目标系统的特权软件控制。具体来说，攻击者可以控制内核空间内的所有特权软件组件，例如操作系统内核和设备驱动程序。除了能够控制这些组件的代码执行之外，攻击者还能够检查和观察主内存中的数据并管理系统地址映射，这是一组指示主内存和 MMIO 访问请求应路由到何处的信息。我们还假设CPU包和GPU卡是可信的，并且GPU有自己独立的设备内存。

Out of Scope

与SGX的防御范围一致，我们不考虑对CPU包的物理攻击和基于侧通道的攻击[9]。我们的目标不是防范在飞地和GPUs内运行的用户代码中的实现错误[11]，诸如不安排特定流程之类的可用性攻击不在我们的范围内。

部分源于我们从 Intel SGX 继承的限制，HIX 具有一些特定于 PCIe 设备和 I/O 互连架构的限制。对 PCIe 互连和 GPU 的物理攻击，例如使用特殊硬件直接在 I/O 通信路径中注入 PCIe 数据包或物理访问 GPU 内存，不属于 HIX 的范围。这是我们做出的固有权衡，因为这项研究基于未修改的 GPU 硬件。无法将 PCIe 对等事务功能与受 HIX 保护的 GPU 结合使用。虽然最新的 GPU 支持 GPU 中的按需页面错误机制 [10, 16]，但 HIX 支持的 GPU 计算模型仅限于传统模型，即要求所有数据在 GPU 内核之前都位于 GPU 设备内存中执行。此外，我们不解决以资源耗尽或拒绝服务攻击的形式针对 GPU 的可用性攻击。我们将在第 5.6 节中更详细地讨论这些限制。

HIX Architecture

Architecture Overview

HIX 设计的一个关键原则是在软件和硬件级别保护从用户应用程序到 GPU 的命令和数据路径。在典型的不受保护的设置中，GPU 驱动程序是操作系统 (OS) 的一部分，并且通过 MMIO 到 GPU 的 I/O 路径由操作系统控制。然而，在提出的 HIX 架构中，GPU 驱动程序与操作系统分离，在安全的 enclave 中运行。操作系统无法影响到 GPU 的 MMIO 映射和路由。为了提供安全计算，必须支持以下软件和硬件组件。

Isolated GPU management with GPU enclave

为了在易受攻击的操作系统下实现安全的 GPU 计算，HIX 将 GPU 驱动程序与操作系统空间分开。 GPU驱动运行在TEE环境上，称为GPU enclave，如图3所示。只有GPU enclave才允许访问GPU MMIO区域，保护GPU MMIO免受恶意操作系统的侵害。

Secure hardware I/O path

GPU enclave 通过 MMIO 发送命令和数据来专门管理 GPU，因此必须确保通过 MMIO 进行的通信不受操作系统和其他应用程序的影响。它需要对 SGX 支持以及 PCIe 架构进行多项硬件扩展。首先，与 enclave 内存保护类似，一旦为 GPU enclave 建立了映射，操作系统就不允许更改 GPU MMIO 区域的虚拟到物理地址映射。其次，必须禁止从 GPU enclave 到 GPU MMIO 区域以外的任何访问。第三，一旦 GPU enclave 初始化，PCIe root complex中的 GPU MMIO 映射和路由配置就不得更改。最后，必须保护进出 GPU 的 DMA 数据免受恶意操作系统的影响。

Trusted application-to-GPU communication

为了安全的GPU计算，GPU请求从用户enclave转移到GPU enclave，GPU enclave代表用户enclave向GPU发送相应的命令。 HIX 利用证明和对称加密来确保用户和 GPU enclave 之间的安全通信。

表 1 总结了所需的硬件和软件更改。随着硬件和软件的变化，HIX 为用户 enclave 提供可信的 GPU 服务，支持敏感数据的机密性和完整性以及安全执行。

GPU Enclave

如图 3 所示，HIX 设计的核心是用户模式 ​​GPU enclave，它负责两项功能：(1) 对 GPU 的唯一控制，以及 (2) GPU 的唯一用户访问接口。为了减少攻击面，HIX 将控制 GPU 的关键功能与操作系统驻留驱动程序分开，并将其隔离在 GPU enclave 内。操作系统中驱动程序其余部分的作用被简化为提供良性内核服务，例如为分配给 GPU enclave 的 MMIO 区域分配新的虚拟地址。在初始化期间，GPU enclave 会重置 GPU 状态，以消除 GPU 中加载的可能不受信任的 GPU 程序。 SGX 支持 GPU enclave 所需的扩展是允许 GPU enclave 访问独占 GPU MMIO 区域，防止所有其他软件访问 GPU MMIO 区域。

GPU MMIO Registration

HIX 提供扩展的 SGX 指令来安全地管理与 GPU 管理和数据复制相关的 GPU MMIO 区域。硬件需要知道 (1) 哪个 MMIO 区域应该受到保护（MMIO 区域的物理地址），(2) 它在 GPU enclave 的虚拟地址空间中映射到什么位置（MMIO 区域对应的虚拟地址），以及 (3 ）应允许访问哪个 GPU enclave，以保护硬件 I/O 路径免遭未经授权的访问。为了注册 GPU MMIO 区域，添加了两条新指令：EGCREATE 和 EGADD，类似于 Intel SGX 指令 ECREATE 和 EADD。

Intel SGX 将 SGX 内部数据结构存储在无法通过软件访问的 EPC 内存页中。同样，HIX 在 EPC 内存页中存储用于 GPU 管理的附加内部数据结构。其中两个隐藏数据结构是 GPU enclave 控制结构 (GECS) 和可信 GPU MMIO 区域 (TGMR) 表，它们类似于常规 enclave 的 SGX enclave 控制结构 (SECS) 和 enclave 页缓存映射 (EPCM)。 GECS 包含有关 GPU enclave 的控制信息，包括硬件 GPU 编号和 GPU enclave ID。 TGMR包含GPU MMIO区域的虚拟和物理地址映射信息，用于验证MMIO区域的地址映射。

图 4 说明了如何使用 GPU enclave 的安全元数据结构。在初始化期间，GPU enclave 进程使用 EGCREATE 指令创建 GPU enclave，GPU 编号由总线、设备和功能编号组成，从可信 PCIe root complex 提供的 PCIe 接口检索。然后将创建的 GPU enclave ID 和 GPU 编号对存储在 GECS 中。 HIX 硬件确保给定的 GPU 是真正的硬件GPU，并且没有GPU同时注册到两个GPU enclave。创建后，GPU enclave 使用 EGADD 指令将虚拟地址和 MMIO 物理地址对注册到 HIX。在注册过程中，HIX 检查虚拟地址和 MMIO 地址对于 GPU enclave 和所属 GPU 设备是否有效，如果验证通过，则将其存储到 TGMR 表中。注册的 MMIO 区域通过使用虚拟到物理地址映射保护的验证进行访问保护，类似于 SGX 常规飞地。 MMIO 访问保护机制详见第 4.3.1 节。

GPU Initialization and Measurement

创建并加载 GPU enclave 后，它会初始化 GPU 状态以清除 GPU 中任何潜在的恶意代码。此外，GPU enclave 还会读取并测量 GPU BIOS，这些 BIOS 在创建 GPU enclave 之前可能已被破坏。需要注意的是，一旦创建了GPU enclave，GPU enclave就拥有对GPU的独占控制权，因此即使是操作系统也无法更改GPU的BIOS。

验证 GPU 硬件通过两个步骤完成：(1) 验证 GPU BIOS 的完整性，(2) 重置 GPU 以消除潜在的恶意代码。 GPU enclave 从存储在 PCIe 扩展 ROM 基地址寄存器中的地址读取 GPU BIOS 字节码。一旦 GPU BIOS 被验证为正版，HIX 就会启动 GPU 的重置步骤，清理 GPU 设备状态。

GPU Protection on GPU Enclave Termination

尽管 HIX 不解决可用性攻击，但当 GPU enclave 不可用时，HIX 仍然负责保护 GPU 中的数据。即使对手强行杀死 GPU enclave，GPU 也会受到 HIX 硬件的保护。由于被杀死的GPU enclave进程仍然拥有GPU，因此任何软件都无法再访问该GPU，甚至新创建的GPU enclave进程也无法拥有该GPU。因此，GPU 中的用户数据仍然无法访问并受到保护。 GPU只能在系统关闭并重新启动后才能再次使用。在系统冷启动过程中，GPU内存和寄存器状态全部重置，并且GECS和TGMR表中存储的GPU注册信息被清除。

如果操作系统请求 GPU enclave 正常终止，GPU enclave 将中止整个 GPU 执行，清除 GPU 数据，并将 GPU 返回给操作系统。用户 enclave 会收到 GPU enclave 已终止且 GPU 不再受信任的通知。

Securing I/O Path: MMIO and DMA

确保 GPU 计算安全的下一步是保护通往 GPU 的命令和数据路径。到 GPU 的命令路径是通过 MMIO 访问的 PCIe 互连，并且数据可以通过MMIO和DMA传输。本节介绍 HIX 的 I/O 路径保护。

MMIO Access Protection

baseline SGX EPC 访问保护机制使用 EPCM 中的信息验证转换后备缓冲区 (TLB) 中的虚拟到物理映射。 HIX 使用 GECS 和 TGMR 对其进行扩展，以保护 MMIO 区域的地址转换，如图 4 所示。当软件使用虚拟地址访问 MMIO 区域时，MMU 使用 TLB 将其转换为物理地址。对于 TLB 未命中，在将 TLB 条目添加到 TLB 之前，硬件页表遍历器通过以下四个比较来验证它：(1) 通过将其 enclave ID 与 GECS 进行比较，当前进程是 GPU enclave，(2) 虚拟进程新的 TLB 条目中的地址与 GPU enclave 请求的地址匹配，(3) 新的 TLB 条目中的虚拟地址与 TGMR 中的虚拟地址匹配，以及 (4) 新的 TLB 条目中的物理地址与 TGMR 中的物理地址匹配。仅当验证成功时，该条目才会被添加到 TLB 中。否则，访问将被拒绝。验证保证只有合格的 GPU enclave 才能访问其自己的 MMIO 区域。

此访问验证步骤与常规飞地基本上共享相同的机制，部分共享用于验证的相同硬件逻辑组件。与常规 SGX enclave 的一个细微差别是使用专用于 GPU enclave 的 enclave 元数据（GECS 和 TGMR）来保护 GPU MMIO 区域。对于常规 enclave，未更改的 SGX 不考虑保护对 MMIO 区域的访问。

MMIO Lockdown and Securing PCIe Routing

在传统架构中，特权系统软件可以重新映射MMIO区域，甚至可以通过修改存储有关MMIO区域信息的基址寄存器（BAR）等PCIe设备寄存器来恶意修改PCIe数据包路由方向。为了保证 MMIO 区域映射以及 PCIe 消息到 GPU 的路由不被恶意软件修改，HIX 在 PCIe root complex 中提供了 MMIO 锁定机制。

调用 EGCREATE 时启用 MMIO 锁定功能，以冻结 MMIO 地址映射。处理器必须冻结 PCIe root complex和 GPU 之间所有 PCIe 设备的 MMIO 配置寄存器。有关 MMIO 区域和 PCIe 路由的所有信息都存储在硬件寄存器中。启用锁定后，PCIe root complex会拒绝所有尝试修改 MMIO 地址映射和路由配置的 PCIe 配置写入请求。PCIe root complex能够通过检查 PCIe 配置事务数据包中的目标设备编号和寄存器偏移量来检查写入请求的目的地，以修改寄存器值 [5,19,43]。如果数据包的目的是修改与PCIe相关的寄存器路由或 MMIO 映射，PCIe root complex只是将其丢弃。除了 EGCREATE 期间的锁定之外，HIX 还扩展了 SGX，以安全地测量 MMIO 配置寄存器值，作为 GPU enclave 测量的一部分。

Trusted DMA

在恶意操作系统下，通过 DMA 进行的数据传输并不安全。 DMA 内存区域不受 SGX 保护，此外，操作系统可以通过将目标缓冲区分配给任意内存页面或通过破坏 IOMMU 页表将 DMA 数据路由到任何内存页面。因此，为了支持 HIX 中 DMA 数据的机密性和完整性，必须使用消息验证码 (MAC) 对通过 DMA 传输的数据进行加密和完整性保护。通过对 DMA 数据的保护，不受保护的缓冲区中仅存在加密的 DMA 数据，并且完整性由 MAC 验证。因此，操作系统无法破坏 DMA 数据的机密性和完整性。在用户 enclave、GPU enclave 和 GPU 之间，密钥按照第 4.4.1 节中的讨论进行安全交换。通过安全密钥交换，通过不可信 DMA 机制进行的通信受到保护。

Application-to-GPU Communication

由于GPU enclave单独控制GPU，因此它应该为用户enclave提供可信的GPU服务接口。图 5 显示了用户 enclave 和 GPU enclave 之间的通信路径。请注意，GPU enclave 可以同时使用不同密钥针对多个用户 enclave 建立安全连接。

Trusted Runtime User Library

HIX 为应用程序提供可信用户运行时库，该库在每个应用程序飞地中运行。该库由GPU API（例如内存复制或GPU内核启动操作）、包含密钥初始化和用户数据加密的安全模块以及用于数据传输的通信模块组成。该库有助于使用 HIX 进行可信 GPU 执行的应用程序开发。在 GPU 应用程序的用户飞地中，可信用户运行时负责与 GPU enclave 的安全交互，隐藏 HIX 用户端软件组件的详细信息。

Secure Inter-Enclave Communication

GPU 管理和 GPU 服务功能从操作系统设备驱动程序移至 GPU enclave，后者作为单独的用户空间进程运行。因此，必须建立一个确保用户飞地、GPU飞地和GPU之间传输数据的机密性和完整性的通信通道。为了通过不受信任的 Interenclave 共享媒体提供传输数据的机密性和完整性，HIX 使用对称验证加密。用户 enclave 和 GPU enclave 执行 SGX 支持的本地证明以相互验证。一旦他们通过证明建立了信任，他们就会使用 Diffie-Hellman 密钥交换协议创建共享对称密钥。由于 Diffie-Hellman 密钥交换可以在多方之间进行，因此 GPU 也参与此密钥设置过程并生成共享对称密钥。

GPU enclave 使用两个与每个用户 enclave 的通信通道；消息队列和共享内存。消息队列用于通信同步，共享内存用于实际的加密数据传输。用户enclave首先将加密数据写入enclave间共享内存，并通过消息队列传输请求，唤醒GPU enclave。然后，GPU enclave 使用共享密钥解密后，使用共享内存中的数据处理请求。

Secure Communication between the GPU Enclave and GPU

一旦建立了信任并共享了密钥，两个飞地就可以通过共享内存等不安全介质进行安全通信。在 GPU enclave 和 GPU 本身之间，通过可信 MMIO 到 GPU 设备建立安全通信路径。 GPU 命令缓冲区分配在受信任的 MMIO 区域中，并受到 HIX 的 MMIO 访问保护的保护。 GPU enclave 通过安全命令缓冲区将用户 enclave 请求的命令发送到 GPU。

从用户 enclave 到 GPU 的内存复制操作的一个简单设计是首先将用户加密数据复制到 GPU enclave。 GPU enclave 使用不同的密钥进行解密和重新加密，并将数据再次复制到 GPU。为了消除不必要的数据复制和加密，HIX设计采用单副本机制，用户enclave、GPU enclave和GPU共享一个密钥。 GPU enclave向GPU发送命令，将enclave间共享内存中的用户加密数据复制到GPU内存（cuMemcpyHtoD），或者直接将GPU内存中的数据复制到enclave间共享内存（cuMemcpyDtoH）。这种设计减轻了密码学和数据的开销复制。 GPU enclave在将加密数据从共享内存复制到GPU内存之后执行GPU内解密，或者在将数据从GPU内存复制到共享内存之前执行GPU内加密。 HIX支持两种数据复制方式； (1) 直接将数据写入映射到 GPU 内存的可信 MMIO，以及 (2) 使用 GPU DMA 引擎复制数据 [26]。这两种方式都使用单副本机制。

Communication Example

本节介绍如何在端点（即用户 enclave 和 GPU）之间安全地传输数据。对于从主机到设备的内存复制（cuMemcpyHtoD），用户enclave首先复制请求的加密元数据（例如数据大小），并通过消息队列向GPU enclave发送cuMemcpyHtoD请求。 GPU enclave解密请求并接受后，用户enclave加密实际数据并将其复制到enclave间共享内存中，并再次通知GPU enclave。与在 GPU enclave 中解密的请求元数据不同，前往 GPU 的用户数据由 GPU enclave 通过 MMIO 或 DMA 直接从 enclave 间共享内存复制到 GPU 内存。然后，GPU enclave启动GPU内解密内核来解密GPU中的数据，并向用户enclave回复数据复制完成。然后，用户飞地可以发送下一个请求，例如启动内核。

Support for Multiple User Contexts

NVIDIA 的 pre-Volta 多进程服务器 (MPS) 允许不同用户进程在 GPU 中并发多内核执行。然而，Volta 之前的 MPS 平台将来自不同用户进程的内核合并到具有多个流的单个 GPU 上下文中，因为当前的 GPU 一次只允许一个 GPU 上下文在 GPU 中执行 [24, 37]。由于即使来自不同用户进程的内核也共享相同的 GPU 上下文（包括地址空间），因此内核可以访问不同内核使用的地址范围 [37]。

与 Volta 之前的 MPS 不同，HIX 创建多个 GPU 上下文，每个上下文针对每个用户 enclave，以将用户 GPU 地址空间与其他地址空间隔离。每个用户 enclave 都与 GPU enclave 建立一个唯一的密钥，以实现安全通信。 GPU enclave 为用户 enclave 创建单独的 GPU 上下文并维护每个用户的密钥。 GPU多上下文执行是通过GPU中的上下文切换来完成的。如果当前上下文没有任何待处理的内核执行请求，则会发生上下文切换到不同的上下文[16]。

先前的研究报告称，GPU 上下文切换和内存释放如果不小心完成，可能会通过共享内存和全局内存泄漏信息 [17,45,51]。为了防止此类数据泄漏，GPU 运行时系统必须清理已释放的全局内存并共享内存。 GPU 中上下文切换的高成本将对 HIX 的性能产生不利影响。最新的 NVIDIA Volta 架构支持更好的隔离同步执行，为每个客户端提供完全独立的 GPU 地址空间 [38]。如果 GPU 端对并发多上下文执行的支持可用，那么通过该支持改进 HIX 是我们未来的工作。

Evaluation

本节介绍了仿真系统上的 HIX 原型实现，并评估其性能开销。此外，本节还根据 HIX 的设计原则对 HIX 的安全性进行了定性评估。

Trusted Computing Base (TCB)

HIX 通过内存加密和访问限制的组合来保护 [36]。在表 2 中，我们列举了 HIX TCB 的组件，以及它们各自的攻击面和保护机制。为了在不进行任何修改的情况下在商用 GPU 上运行，我们通过访问限制来保护 GPU 硬件资源，其中修改后的 MMU 拒绝除 GPU enclave 之外的所有访问。可信 PCIe I/O 路由机制可确保数据包通过 PCIe 根联合体的 MMIO 锁定到达所需的 GPU。此外，用于访问验证的辅助控制数据结构通过基于硬件的 SGX 保护进一步得到保护，该保护将数据加密存储在 EPC 页中，并且不允许软件访问它。采用 Intel SGX 保护的 Enclave 与受身份验证加密保护的 Enclave 间共享内存进行通信。

Prototype Implementation

我们使用系统虚拟化和仿真实现了 HIX 原型。软件组件（例如 GPU enclave 中的可信 GPU 驱动程序以及跨用户 enclave、GPU enclave 和 GPU 的受保护通信机制）是在仿真系统之上实现的。系统仿真使用KVM-SGX [22]和QEMU-SGX [23] 由 Intel 提供，用于在guest 虚拟机中启用 SGX 功能。

通过仿真支持所需的硬件修改，例如 MMIO 锁定和新指令。对于新的 HIX 指令，我们通过使用 ENCLExiting 位图 [18] 对 SGX 指令使用条件 VM 退出机制。它是虚拟机控制结构（VMCS）中的一个 64 位字段，位图的每个位位置都会强制相应的 SGX 指令导致 VM 退出。指令和内部数据结构在KVM中实现并由VM退出处理程序管理。 PCIe MMIO 锁定在 QEMU 的模拟 IOH3420 PCIe 根端口设备中实现。如果请求修改了 MMIO 路由的寄存器，则修改后的 PCIe 根设备将拒绝对 PCIe 配置空间的写入请求。 TLB条目验证，检查MMIO地址是否被修改或者对手是否正在访问受信任的MMIO，在KVM的EPT违规处理过程中被模拟[54]。

对于运行在 GPU enclave 上的 GPU 驱动程序，我们使用 Gdev，一个用于 GPU 计算的开源 CUDA 平台 [27, 28]。 Gdev 被修改为在修改后的 SGX enclave 上作为 GPU enclave 运行。在Gdev设计中，GPU驱动程序和GPU之间的同步是通过MMIO轮询而不是中断来完成的。

静态 HIX 可信库链接到用户 enclave 以进行 enclave 间通信，并提供与相应 CUDA 驱动程序 API 几乎相同的基本应用程序编程接口 (API)。因此，程序员可以像使用现有的 CUDA API 一样轻松地使用 HIX。我们使用 OCB-AES-128 进行身份验证用于数据机密性和完整性保护的加密算法[33]。 Intel SGX-SSL库用于Enclave中的加密和解密，我们基于OpenSSL OCB实现和RFC7253规范[14,21,33,46]实现了GPU加密功能。

为了减轻加密开销，HIX 中的内存副本是管道化的；即经过验证的加密或解密和实际的复制操作是并行操作的。 HIX将一个大数据块分成多个较小的块，并在加密的第n个块的传输过程中对第n+1个块进行加密。

Performance Overhead

我们评估了 HIX 在两种工作负载场景下的性能开销。首先，我们使用矩阵加法和乘法的微基准来评估从用户 enclave 发起的应用程序到 GPU 中完成的整个执行阶段。接下来，我们使用 Rodinia 基准测试来实现更现实的工作负载场景 [6, 7]。每个测试测量五次，并显示平均值。

我们在具有 GPU 和支持 SGX 的 CPU 的系统上执行评估。表 3 列出了用于评估的系统配置。在本节中，Gdev 表示使用原始不安全的 Gdev 平台运行。

Matrix Operation Microbenchmarks

为了分析 HIX 的性能，我们首先使用简单的矩阵运算：整数矩阵加法（A + B = C）和整数矩阵乘法（A × B = C），并比较各种数据大小下 HIX 与原始 Gdev 的结果。表4以矩阵大小表示输入和输出数据的大小。请注意，我们用于测试的 GPU (NVIDIA Geforce GTX 580 [由于 Gdev 对 GPU 架构的支持的可用性，本研究中选择了特定的 GPU。]) 具有 1.5GB 内存容量，因此我们无法测量内存使用量大于 1.5GB 的矩阵运算的性能。

结果如图 6 所示。对于计算与通信比率较低的矩阵加法，加密操作的开销在其他成本中占主导地位，导致执行速度比 Gdev 慢 2.5 倍。然而，对于矩阵乘法，与加法相比，计算时间急剧增加，使得安全开销只占计算时间的一小部分执行时间。对于与 11264×11264 输入大小的乘法，HIX 只比原始 Gdev 慢 6.34%。分析表明，HIX 中的大部分性能开销来自用户 enclave 和 GPU 之间的经过身份验证的加密开销。 HIX 的性能成本很大程度上取决于 GPU 中的计算比例以及 CPU 和 GPU 之间的通信比例。

Rodinia Microbenchmarks

表 5 列出了从 Rodinia 基准测试套件中选择的应用程序列表，以及 CPU 和 GPU 之间传输的数据量以及问题大小。应用程序选择遵循最初的 Gdev 评估中使用的应用程序选择，尽管由于移植问题而有一些细微的变化。

图 7 显示了所选 Rodinia 基准应用程序的结果。 HIX 的性能平均比不安全的 Gdev 低 26.8%。当计算与通信比率较高（如 GS 所示）时，HIX 表现出与 Gdev 相当的性能。然而，对于大数据传输的应用程序（BP、NW 和 PF），性能下降幅度更大，分别为 81.5%、70.1% 和 154%。此外，HIX 中的任务初始化开销略低，因此 HS、LUD 和 NN 中的小型内核启动在 HIX 中比 Gdev 更快。

Multi-User Execution

在本节中，我们评估多个用户同时请求GPU服务时的性能。结果如图 8（为 2 个用户提供服务）和图 9（为 4 个用户提供服务）所示。执行时间已标准化为单个用户的 Gdev 的执行时间。由于 HIX 包含多个 GPU 内加密内核执行，因此加密内核执行本身的开销、上下文切换的增加以及小数据加密的资源利用不足，使得 HIX 性能比 Gdev 差。 HIX 并行执行显示，与 Gdev 并行执行相比，两个用户时的性能差约 45.2%，四个用户时的性能差约 39.7%。不过性能还是比GPU enclave运行的执行场景要好按顺序收到请求。一旦通过引入最新的 NVIDIA Volta 架构来支持无需上下文切换的并发多用户执行，性能下降预计将显着减少。

Security Analysis

我们首先提出 HIX 所依据的一组最小安全公理，并分析 HIX 如何防御给定这些公理的攻击类别。我们假设以下安全公理对于 HIX 有效：

公理 #1 - 硬件信任根：GPU 和支持 SGX 的 CPU 都是可信的，不会受到物理攻击。

公理 #2 - SGX 支持的安全性：SGX 保留 enclave 内运行的代码的完整性以及 enclave 中运行时存储的数据的机密性。

公理 #1 保证可信 CPU 的存在，确保 SGX 按设计正确运行。此外，它还假设 GPU 硬件本身是可信的，因为对其进行物理攻击超出了范围。 公理 #2 确保 SGX 飞地内代码和数据的机密性和完整性。在 enclave 中执行的代码（在用户 enclave 和 GPU enclave 中）可以被证明和验证是否符合预期。

在图 10 中，我们说明了往返于用户应用程序和 GPU 的往返用户数据流，并突出显示了用圆圈数字表示的 HIX 攻击面。我们设计 HIX 来防范这些可能的攻击点。

Data Confidentiality and Integrity Attacks

攻击者可以针对两种形式的数据，即（1）运行时两个实体之间的通信数据，以及（2）实体中正在使用或静态存储的计算数据。

首先，为了保护 Axiom #1 所涵盖的可信实体之外的通信数据，HIX 保护安全区间共享内存通信通道 (1)、MMIO 路径 (3) 和 PCIe 路由路径 (4)。为了保护 enclave 间的通信，HIX 使用 Intel SGX 本地证明和 Diffie-Hellman 密钥交换协议 [12] 来协商 enclave 之间的初始会话加密密钥。随后的请求消息和用户数据的Enclave间通信流将使用OCB-AES认证加密算法进行加密，以确保其机密性和完整性。递增的随机数还用于确保加密消息的新鲜度并防止重放攻击。当数据传输时，它们仍然使用密钥加密，因此在数据到达 GPU 之前仍然保证机密性和完整性。

其次，我们确保关键的临时数据（例如会话加密密钥）在 SGX 硬件强制隔离的范围内保持受到保护 (2)。公理#2 确保秘密数据保持机密并且对手无法访问。会话加密密钥被创建并存储在 GPU 中，但对手仍然无法访问它们，因为 MMIO 只能由符合条件的 GPU enclave 访问，这在 4.3 节中有详细介绍。

Code Integrity Attacks

由于 GPU enclave 介导对 GPU 的唯一访问，因此攻击者可能会在设置过程中尝试破坏 GPU enclave (2) 内运行的代码。 公理 #2 确保飞地内运行的代码的完整性。此外，用户利用 SGX 对 GPU enclave 内运行的代码执行远程证明 [20]。作为证明过程的一部分，GPU enclave 代码以加密方式确认其来源（作为 GPU 供应商提供的代码），并进一步验证它是否未被修改并且确实在真正的支持 Intel SGX 的系统上执行。

MMIO Address Translation Attacks

为了破坏通过 MMIO (3) 在 GPU 和 GPU enclave 之间建立的安全硬件 I/O 路径，攻击者可以尝试将路径端点之一重定向到攻击者控制的实体。实现此目的的两种可能方法是：(1) 在 TGMR 注册期间注册错误的地址对，以及 (2) 修改与 MMIO 相关的页表条目。 HIX 的设计阻止了这些攻击。对于第一类攻击，EGADD 的执行验证虚拟地址和物理地址是否在 GPU enclave 虚拟地址空间和物理 MMIO 区域的正确范围内。在第二种类型的攻击中，注册受信任的 MMIO 区域后，攻​​击者可以尝试修改 MMIO 的页表条目，以将 GPU 和 GPU enclave 之间的流量重定向到攻击者控制的内存区域。为了防止这种情况，页表遍历器检索到的页表条目在使用之前会进行验证，如第 4.3 节所述。

DMA Attacks

攻击者可以修改 DMA 的目标物理地址，并允许将攻击者控制的数据复制到 GPU 或从 GPU 复制 (5)。然而，在 HIX 使用经过身份验证的加密的情况下，这种攻击将不起作用。基于OCB-AES算法检查加密数据的完整性。如果攻击者试图在运行时注入受损数据，GPU 和用户 enclave 将检测到完整性检查失败并中止。当恶意 IOMMU 用于 DMA 时，这种保护仍然有效 [58]。

PCIe Routing Modification Attacks

攻击者可以尝试通过修改中间 PCIe 路由路径来拦截前往 GPU 的 PCIe 数据包 (4)。此外，攻击者可以将数据包从 GPU enclave 重定向到不受信任的目的地，这可能会导致 GPU enclave 使用 GPU 以外的不受信任设备创建密钥。为了防止 PCIe 路由表被修改，GPU enclave 通过 MMIO 锁定来锁定 MMIO 路由信息，然后在初始化期间验证从 PCIe root complex到 GPU 的路由信息​​，如第 4.3.2 节所示。 GPU enclave初始化后，攻击者无法修改从主机到GPU的路由路径。

GPU Enclave Termination Attacks

如第 4.2.3 节中所述，强制终止的 GPU enclave (2) 仍然在硬件（GECS 和 TGMR）中注册为 GPU 的所有者进程。因此，即使是新创建的 GPU enclave 进程也无法访问 GPU，因为 GPU enclave 注册不会随 GPU enclave 终止而重置。只有在电源回收和系统重新启动后才能使用 GPU，从而清除 GPU 及其内存中的所有剩余信息。

GPU Emulation Attacks

拥有特权的对手可以设置模拟 GPU (6)。但是，在 GPU enclave 的安全初始化期间，HIX 会检查 GPU 的硬件状态。由于可信 PCIe root complex仅检索真实设备属性，因此 HIX 可以防止使用模拟 GPU，并保证到实际硬件 GPU 的可信路由。

Limitations

在本节中，我们讨论 HIX 的局限性，这些局限性源于关键设计原则：不对 GPU 架构进行修改。

Physical Attacks on GPUs

GPU没有可信内存区域，GPU内存中的数据以明文形式存在。因此，对 GPU 内存的直接物理访问将会暴露用户数据。此外，由于 PCIe 互连暴露，通过特殊硬件注入恶意 PCIe 数据包是可能的。对于此类数据包注入，保护到 GPU 的路由路径不足以确保通过 MMIO 对 GPU 的控制。

No PCIe Peer-to-Peer Transaction Service

PCIe 点对点 (P2P) 事务服务（例如 NVIDIA GPUDirect）用于高性能系统。本文的HIX设计主要针对单GPU或多GPU系统无需跨 GPU 的 P2P 连接，仅为用户 enclave 和 GPU 之间的通信路径提供保护。研究与 HIX 的 P2P 通信是我们未来的工作。

PCIe feature not supported for MMIO Lockdown

PCI 规范指定了一种获取 MMIO 大小的方法 [41]。然而，大小调整查询涉及全 1 的 BAR 写入，这在 HIX 中的 MMIO 锁定后是不允许的。这个问题是特定于实现的；它可以通过额外的机制来解决，例如，如果 PCIe 根联合体在大小调整查询中写入全 1，则它会异常接受 MMIO 修改。

No GPU Demand Paging Support

最新的 GPU 支持按需分页，通过页面错误将数据从主机动态复制到 GPU，以将 GPU 内存扩展到主内存 [44,47,48]。支持这种请求分页需要在写回主存储器之前对页面进行额外的加密和完整性保护。然而，由于开源 Gdev 平台缺乏需求分页支持，我们的原型并没有提供该功能。添加需求分页将是我们未来的工作。

Related Work

最近与 HIX 并行进行的一项研究 Graviton 提出了通过 GPU 提供的隔离执行在 GPU 上进行可信计算 [52]。 Graviton 提出修改 GPU 硬件，以防止设备驱动程序直接访问几个关键的 GPU 接口，例如通信通道、页表条目等。与 Graviton 不同，HIX 专注于通过 I/O 组件的硬件扩展来保护商用 GPU SGX在CPU端支持。

最近有几项研究旨在提高 SGX 当前系统的安全性。在 SCONE [2] 中，docker 容器在 SGX enclave 内运行。它使用异步系统调用接口将容器的系统调用请求快速传递到enclave外部。金等人。使用 SGX 来增强匿名网络软件的安全性，以解决其当前的局限性 [30]。最近有几项研究旨在减少 SGX 内存容量的限制。 Eleos 提出了一个通用库，用于将数据存储在 enclave 之外的安全内存池上 [40]。 ShieldStore 和 SPEICHER 提出了特定于应用程序的键值存储方法，以将数据安全地保存在不受信任的内存上 [3, 31]。

有几项研究分析了 GPU 的安全漏洞。 CUDA Leaks [45] 展示了 GPU 数据如何泄露给恶意用户，Zhu 等人。 [58]分析了GPU架构及其潜在的安全漏洞。 PixelVault 使用 GPU 硬件作为密钥的安全存储，利用 GPU 和 CPU 之间的物理隔离[51]。由于 GPU 通常会在内存分配或释放时重用未初始化为零的内存块，攻击者可以从 GPU 内存中检查过去计算会话的残留信息 [17,29,34,56]。

最近的研究调查了 I/O 设备及其计算的安全性。边界控制提出了带有加速器的异构系统的安全性[39]。该研究的重点是保护系统免受潜在恶意加速器的影响，而 HIX 提供安全的 GPU 和加速器计算，与受损的特权软件隔离。 SUD 通过在用户空间中提供模拟内核环境来将潜在的恶意设备驱动程序与内核空间隔离[4]。

几项研究调查了基于虚拟机管理程序的方法 [53, 57] 和基于系统管理模式 (SMM) 的方法 [32]，以提高不可信操作系统下用户和 I/O 设备之间的安全性。 SGXIO 利用经过正式验证的虚拟机管理程序在用户应用程序和 I/O 设备之间提供可信路径 [53]。虚拟机管理程序上的可信设备驱动程序为 enclave 中的用户应用程序提供设备服务。然而，SGXIO 并未研究其面向性能的 GPU 计算方法。 SGXIO 依赖于设备虚拟化，这对 GPU 具有很高的性能开销。最近对全 GPU 虚拟化的研究表明，性能开销明显高于本机执行 [50, 55]。

本文提出了一种硬件和软件架构来保护 GPU 计算免受恶意特权软件的侵害。 HIX 将 I/O 互连和 GPU 驱动程序与操作系统的控制隔离开来，无需对硬件 GPU 架构进行任何更改。虽然本文重点关注与 PCIe 总线连接的离散 GPU 平台，但通过应用所提出的设备隔离原则，HIX 可以扩展为支持通过 I/O 互连与 CPU 通信的各种加速器架构。仿真系统上的原型实现展示了通过较小的硬件 I/O 互连更改进行安全 GPU 计算的可行性。