当今数据中心的 GPU 拥有悠久而辉煌的 3D 图形传统。在 20 世纪 90 年代,用于 PC 和游戏机的图形芯片具有固定的流水线,用于使用整数和定点运算的几何、光栅化和像素处理。1999 年,NVIDIA 发明了现代 GPU,它将一组可编程核心置于芯片的核心位置,从而能够高效地生成丰富的 3D 场景。开发者和研究人员很快意识到“我可以在这些并行核心上运行计算,速度会非常快。” 2004 年,Ian Buck 在斯坦福大学创建了 Brook,这是第一个用于 GPU 的计算库,2006 年,NVIDIA 创建了 CUDA,它是当今 GPU 上加速计算的黄金标准。
除了运行 3D 图形和计算外,GPU 还运行视频工作负载,包括播放受保护内容(如好莱坞电影)的能力。为了保护此类内容,NVIDIA GPU 包括硬件和固件来保护 GPU 内存区域,该区域保存解密和解码后的输出帧。此功能称为 VPR(视频保护区域)。当 GPU 内存区域设置为 VPR 时,除了可以从 VPR 读取并写入 HDMI 或 DisplayPort 通道的安全显示引擎外,任何从该区域读取的引擎如果尝试写入 VPR 外部,都会发生故障。当开始讨论 CC(机密计算)时,我们在 NVIDIA 的一些人开始集思广益,思考问题:“我们可以利用 VPR 或类似方法来进行机密计算吗?” 我们意识到 NVIDIA 的 Ampere 系列 GPU 为部分机密计算模式提供了构建模块。新的固件可以在 GPU 内存中启用用于受保护计算的飞地,其中
• 只有 SEC2 安全微控制器可以从飞地读取和写入外部;并且当它写入外部时,它将首先加密数据。
• 如果所有其他引擎尝试写入飞地外部,则会发生故障。
CC 要求数据和代码同时具有保密性和完整性。保密性意味着攻击者无法读取数据和代码。完整性意味着攻击者无法修改执行,例如,导致生成错误的答案。利用 Ampere 方法可以为数据提供保密性,但不能为代码提供保密性,并且它既不能保护代码的完整性,也不能保护数据的完整性。此方法称为 APM(Ampere 保护内存),以防止与完整的 CC 功能混淆。我们构建了 APM 的 POC(概念验证),并与 Microsoft 合作在 Azure Private Preview 中启用 APM,要求用户试用并提供反馈。
下一步是为 Hopper H100 GPU 启用完整的 CC 功能。当我们请求必要的 CC 功能时,正值 H100 硬件开发后期,但 NVIDIA 的所有团队齐心协力找到了解决方案。
GPU 机密计算解决方案依赖于 CPU 上的 CVM(机密虚拟机)TEE(可信执行环境),通过 AMD CPU 上的 SEV-SNP 或 Intel CPU 上的 TDX 1.x 启用。图 1 显示了 GPU CC 解决方案的高级架构。
GPU 设备内存在逻辑上划分为受保护和未受保护的内存区域。GPU CPR(计算保护区域)内存受到保护,以便 GPU 可以在其 HBM(高带宽内存)中全速处理数据。有关如何实现此目的的更多详细信息将在稍后分享。从 GPU 外部访问未受保护的 GPU 内存没有任何限制。
当 Hopper GPU 在机密模式下启动时,它会阻止 GPU 内存 CPR 的入口和出口。PCIe(外围组件互连 Express)防火墙阻止 CPU 访问大多数寄存器和所有 GPU CPR 内存,NVIDIA NVLink 防火墙阻止 NVLink 对等 GPU 访问 GPU CPR 内存。
此外,在 CC 模式下运行的硬件引擎具有保护措施,以确保它们无法写入计算保护内存外部,除非它们在此模式下具有硬件强制加密功能。这种方法可以防止引擎将数据泄漏到保护内存外部。
DMA(直接内存访问)引擎是唯一用户模式可访问的引擎,允许读取或写入 CPR 外部。DMA 硬件确保写入 CPR 外部的数据由硬件预先加密,从而确保不会发生数据泄漏。H100 GPU 中的 DMA 引擎为此目的支持 AES GCM 256 加密,并且该引擎用于在 CPU 和 GPU 之间双向传输数据。
CC 通过在基于硬件、经过认证的 TEE 中执行计算来保护正在使用中的数据(请参阅机密计算联盟的定义)。NVIDIA H100 GPU 符合此定义,因为其 TEE 锚定在片上硬件 RoT(信任根)中,并且当它在 CC-On 模式下启动时,GPU 会启用硬件保护,以提供代码和数据的保密性和完整性。
1. 通过 GPU 启动序列建立信任链,并进行安全和测量启动。
2. SPDM(安全协议和数据模型)会话用于安全地连接到 CPU TEE 中的驱动程序。
3. 生成证明报告,其中提供一组加密签名的测量值。
CC 环境中的用户可以检查证明报告,并且只有在报告有效且正确时才能继续。
在 CC 模式下,在 GPU 上运行的固件组件位于 TCB(可信计算基础)内。只有 NVIDIA 签名和证明的固件组件才允许在 CC 模式下运行。
CVM 中的 NVIDIA 驱动程序与 GPU 硬件 TEE 建立安全通道,以传输数据、启动计算和检索结果。为了与硬件通信,每个访客驱动程序组件都使用唯一的加密密钥。
开发了一种新的硬件功能,以创建可以使用 PCIe BAR0(基地址寄存器 0)访问的 GPU 寄存器的有限视图。由于主机或虚拟机监控程序在 CC 模式下不受信任,因此任何危及 CC 模式下 GPU 安全性(危及访客的完整性或保密性)的寄存器都必须受到保护。这项新功能称为 BAR0 解耦器,它允许访问有限的寄存器空间来管理 GPU,同时保护大多数寄存器空间免受主机和虚拟机监控程序的侵害。
为了防止侧信道攻击,硬件强制规定当 GPU 在 CC 模式下运行时,所有 GPU 性能计数器都将被禁用。一种称为 CC DevTools 的新模式支持 CC 模式下应用程序的性能调试。启用 CC DevTools 模式时,会在证明报告中显示。
在未启用 CC 的情况下,虚拟机监控程序可以完全访问系统内存和 GPU 内存。启用 CC 后,虚拟机监控程序将被阻止访问系统内存中的机密 VM,并被阻止读取 GPU 内存,如图 2 所示。
H100 GPU 支持以下操作模式
• 启用 CC (CC = on)
• 禁用 CC (CC = off)
• CC devtools (CC = devtools)
为了使配置更安全,GPU CC 模式被设计为在 PF-FLR(物理功能功能级重置)之间持久存在。GPU CC 模式选择是使用 GPU EEPROM(电可擦可编程只读存储器)中的 H100 GPU CC 控制位完成的,该位可以通过带内工具(如 gpu_cc_tool.py)或通过 OOB(带外)API 设置/取消设置。为了使对此位的更新生效,需要 PF-FLR,它将擦除内存并确保寄存器和 SRAM(静态随机存取存储器)中的所有状态在 GPU 移交给下一个租户之前都已正确重置。
图 3 显示了启用 CC 的 GPU 状态转换。
具有 AMD SEV-SNP CPU 或启用 Intel TDX 的 CPU 的可信 VM 是在 VM 中验证 GPU 的必要条件,然后才能将 GPU 用于机密工作负载。为了验证 GPU 是否有能力并且已准备好运行 CC 工作负载,必须遵循以下步骤
1. 验证 GPU 是否为支持 CC 的合法 NVIDIA GPU。
2. 确保 GPU 未因 CC 而被吊销。
3. 验证 GPU 证明报告。
GPU 的身份验证使用 PKI(公钥基础设施)方法。每个 NVIDIA H100 GPU 都携带唯一的、按设备区分的 ECC(椭圆曲线密码学)密钥对及其对应的公钥证书。NVIDIA 托管 OCSP(在线证书状态协议)服务,允许用户检查证书的有效性以及 CC 的 GPU 吊销状态。
GPU 驱动程序启动密钥交换序列,以与 GPU 建立安全会话,并使用 SPDM 消息与 GPU 进行身份验证、证明和密钥交换。用户必须查询证明报告和证书以证明 GPU,并在成功证明后,将 GPU 就绪状态切换为 ON,以允许 CUDA 程序在 CC 模式下在 GPU 上运行。
为了将 GPU 包含在 CVM 的信任边界中,必须对其进行身份验证以证明其合法性,进行验证以确保其未被吊销,并要求其提供处于良好已知状态的证据。证据以测量值的形式提供,测量值是 GPU 状态的单向哈希,这些状态对其安全性至关重要。证明报告是由被评估设备的 RoT 签名的证据。签名确保测量值不会被更改,并消除了监管链问题。使用已建立的安全通信通道获取证明报告消除了设备欺骗攻击。
获取报告后,CVM(或相关方)必须验证证据的真实性,并评估报告以判断 GPU 是否处于良好的已知状态。评估报告需要一组黄金测量值,称为 RIM(参考完整性清单),RIM 由 NVIDIA 离线生成,并随每个驱动程序和 VBIOS 更新一起发布。将证明报告中的测量值与 RIM 进行比较的过程称为证明验证,执行此过程的实体称为验证器。验证器可以是本地的,内置于 CVM 中;也可以是远程的,由设备制造商或受信任的第三方托管。CVM(或相关方)必须在信任其结果之前验证验证器的身份并确认其合法性。图 4 显示了该序列的高级流程。
图 4 中的序列引入了两个新术语
• RTR(报告信任根)。负责获取存储的测量值、创建报告并使用证明密钥对其进行签名。
• RTS(存储信任根)。跟踪迄今为止收集的测量值的安全存储。
另一个实体 RTM(测量信任根),如图 5 所示,负责测量选定的状态并将测量值保存在 RTS 中。NVIDIA GPU 在固件中实现了一个 RTR,多个 RTM,以及一个硬件 RTS,最多可存储 64 个独立测量值。RTS 硬件支持测量扩展以防止覆盖,并允许跟踪其演变。每个插槽都有一个 RTM 所有者,并存储一个测量值,该测量值是使用一个或多个彼此相关并以有序方式演变的状态计算得出的。
确定 GPU 中要测量的正确状态是一个具有挑战性的问题。理想情况下,测量 GPU 中的所有寄存器、视频内存和 SRAM 将提供 GPU 状态的完整指示,但这在实践中是不可行的,因为状态量庞大且生成用于比较的黄金值非常复杂。为了克服这一挑战,并在合理精度范围内仍然测量 GPU 的当前状态,所选方法是测量选定的高价值寄存器,并证明 CC=On 的 GPU 配置已按预期完成。在图 6 中,测量了寄存器形式的防火墙、选定的熔断器、调试寄存器和所有微码(μcodes)。
还会测量和记录影响设备安全态势的安全事件、错误触发器和用户策略。这些策略不能直接与 RIM 进行比较,但 CVM 可以使用它们来确认已采取预期操作。由于 VBIOS 和 GPU 驱动程序是独立发布的,因此每个都有自己的 RIM,并且验证器需要两个 RIM 进行验证,如图 7 和表 1 所示。
验证器在设置 GPU 以包含在 CVM 信任边界中起着至关重要的作用,这可能有助于依赖方做出决策。根据验证器的运行位置,验证器分为两类:本地验证器(在 CVM 中作为专用进程运行)和远程验证器(由受信任的第三方托管)。
本地验证器是 NVIDIA 提供的独立工具,充当验证器和依赖方。本地验证器附带默认策略,该策略仅允许应用程序在成功完成证明验证后才能使用 GPU。本地验证器是开源的,可由 VMI(虚拟机映像)创建者下载,并且可以作为 CVM 初始化序列的一部分启动。CVM 隐式信任此工具扮演此角色。本地验证器需要 NVIDIA 托管的以下远程服务
• NVIDIA OCSP 服务。验证 GPU、证明和 RIM 文件的证书链。
• NVIDIA RIM 提供商服务。一种远程服务,托管所有驱动程序和 VBIOS 版本的 RIM 文件。验证器使用证明报告中的唯一标识符来获取适当的 RIM 文件。
虽然本地验证器可以快速简单地采用 CC,但它也存在一些可能阻碍长期使用的问题
• 随着支持 CC 的 GPU 产品组合的扩展,本地验证器不可扩展。
• CVM 必须隐式信任本地验证器。
远程验证器通过在远程服务器上托管验证服务并允许依赖方在委托报告验证之前验证托管服务来解决这些问题。NVIDIA 已经启动了这样一项服务,称为 NRAS(NVIDIA 远程证明服务),该服务目前支持 GPU 证明,并且未来可能会扩展以涵盖其他 NVIDIA 产品。除了 NRAS 之外,NVIDIA 还在引入 NVIDIA 证明 SDK,以将 NRAS 流程集成到应用程序中,如图 8 所示。
在正确配置、启动和证明 H100 的 CVM 之后,用户可以开始在其 H100 GPU 上安全地处理数据。我们努力确保尽可能多的直接迁移式编码。目标是让用户的现有代码和内核在启用 H100 CC 模式时无需更改即可工作。
默认情况下,设备被阻止与 CVM 交互,并且无法直接访问 CVM 内存。驱动程序使 H100 能够在 CC 模式下与 CVM 安全地通信。
支持 CC 的 CPU 通过配置 MMU(内存管理单元)来隔离 CVM,以隔离内存页,以便只有关联的 VM 才能访问它。这种隔离不仅仅向未经授权的方呈现加密/签名的数据,而是当关联的 CVM 以外的组件尝试访问它时,会发生页面错误。
在图 9 中,H100 GPU 分配给 VM[1],VM[1] 已配置其关联的内存 ASID(地址空间标识符)[1]。除非 VM[1] 特别将某些页面标记为“共享”(ASID[1] 内的灰色框),否则从 VM[1] 外部访问 ASID[1] 中的内存将导致前面提到的错误。
H100 GPU 具有带加密/解密功能的 DMA 引擎,负责 CPU 内存数据的来回移动。在机密环境中,DMA 引擎可以访问共享内存页以检索和放置数据。为了确保有效负载、模型和数据的保密性和完整性,这些页面中的数据已加密和签名。这些共享内存区域称为反弹缓冲区,因为它们用于暂存安全数据,然后再将其传输到安全内存飞地、解密、身份验证,然后进行处理。
图 10 显示了 CPU 内存和 GPU 内存的布局以及加密反弹缓冲区的位置。
NVIDIA 为开发人员提供了一种名为 UVM(统一虚拟内存)的解决方案,该解决方案根据名为 cudaMallocManaged()
的内存分配 API 自动处理 GPU 内存和 CPU 内存之间的页面迁移。当 CPU 访问数据时,UVM 会将页面迁移到 CPU 系统内存。当 GPU 需要数据时,UVM 会将其迁移到 GPU 内存。对于 CC,UVM 扩展为通过共享内存中的反弹缓冲区使用加密和经过身份验证的分页。
以下是开发人员在使用 CC 模式下的 H100 时应注意的一些注意事项的摘要。
• 由于 CPU 供应商如何将 CVM 内存与外部来源隔离,因此 GPU 无法直接访问诸如 cudaHostAlloc()
和 cudaMallocHost()
之类的固定内存分配。相反,它们由 UVM 通过加密分页处理,就像它们是由 cudaManagedAlloc()
分配的一样。这意味着在 CC 模式下,固定内存访问速度较慢。
• 不支持 cudaHostRegister()
,因为此 API 允许直接访问 CVM 内部由 malloc()
或 new()
创建的内存。当 GPU 处于 CC 模式时,此 API 以及其他一些 API 将返回错误代码。cudaHostRegister()
在 NVIDIA 库中没有广泛使用,并且在我们使用它的地方,我们正在修改代码路径以在 CC 模式下与 H100 无缝协作。
• 开发人员在使用 CC 模式下的 H100 GPU 时必须使用 nvidia-persistenced
守护程序,以保持驱动程序加载,即使在不使用时也是如此。在典型操作中,当不再使用 NVIDIA 设备资源时,NVIDIA 内核驱动程序会拆除设备状态。但是,在 CC 模式下,这将导致销毁在驱动程序的设置 SPDM 阶段建立的共享会话密钥。为了保护用户数据,GPU 不允许在没有 FLR 的情况下重新启动 SPDM 会话建立,FLR 会重置和擦除 GPU。nvidia-persistenced
提供了一个名为持久模式的配置选项,该选项可以由 NVIDIA 管理软件(如 nvidia-smi
)设置。启用持久模式后,将阻止 NVIDIA 内核驱动程序退出。nvidia-persistenced
不使用任何设备资源;它只是在休眠状态下保持对 NVIDIA 设备状态的引用。
考虑到这些注意事项,用户可以继续在 CC 模式下使用 H100 GPU。
为客户提供 CC 的主要目标是,CUDA 应用程序可以在保持不变的情况下运行,同时最大限度地提高底层硬件和软件的加速潜力。CUDA 为将在 CC 模式下运行的应用程序提供直接迁移的好处。因此,NVIDIA GPU CC 架构与 CPU 架构兼容,CPU 架构也提供从非机密环境到 CC 环境的应用程序可移植性。
鉴于到目前为止的描述,当计算量与输入数据量相比很大时,GPU 上的 CC 工作负载的性能接近非 CC 模式应该不足为奇。当计算量与输入数据量相比很小时,跨非安全互连进行通信的开销会限制应用程序吞吐量。
为了帮助了解 CC 模式下的性能,以下性能原语与非机密模式相当
• GPU 原始计算性能。 计算引擎在 GPU 内存中的未加密数据上执行未加密的代码。
• GPU 内存带宽。 封装上的 HBM 被认为是安全的,可以抵御常见的物理攻击工具(如中间人攻击器),并且未加密。
以下性能原语受到额外加密和解密开销的影响
• CPU-GPU 互连带宽受到 CPU 加密性能的限制。目前,这大约为 4GB/秒。
• 跨 PCIe 总线的数据传输会因通过共享内存中的加密反弹缓冲区的传输而产生延迟开销。
图 11 显示了具有处于和未处于 CC 模式的 GPU 的示例服务器拓扑。
GPU 命令缓冲区、同步原语、异常元数据以及在 GPU 和在 CPU 上运行的机密 VM 之间交换的其他内部驱动程序数据也存在加密开销。加密和验证这些数据结构可以防止对用户数据进行侧信道攻击。
图 12 显示了具有高计算与 I/O 比率的工作负载示例,图 13 是具有低计算与 I/O 比率的工作负载示例。BS 是批大小,SL 是序列长度。
对于 H100 Tensor Core GPU,CC 作为 CUDA 12.2 的早期访问功能提供,CUDA 12.2 于 2023 年 7 月发布。在我们完成性能优化并允许足够的安全浸泡时间后,CC 功能将全面上市。此功能提供的关键价值主张是
• 我们将 CC 带给要求最苛刻的工作负载,如 AI、机器学习和高性能计算。
• 现有 CUDA 程序、深度学习框架等无需更改即可运行。
• 用户代码和用户数据受到端到端保护。
• GPU 及其固件作为整个平台证明的一部分进行证明。
创建首款机密 GPU 对于 NVIDIA 的整个团队以及我们在其他致力于机密计算愿景的公司的合作者来说,都是一次激动人心的旅程。今天,机密计算是一项伟大的创新。在几年后,我们预计所有计算都将是机密的,我们将想知道为什么曾经是其他方式。
Gobikrishna Dhanuskodi 是 GPU 系统软件组的杰出工程师,也是 NVIDIA GPU 机密计算的首席软件架构师。在他在 NVIDIA 的长期任职期间,他主要从事产品安全、DRM 解决方案和 GPU 虚拟化技术方面的工作。他目前专注于在加速计算中启用 CC 技术,并使其在更广泛的用例中普及。
Sudeshna Guha 是 NVIDIA 的高级系统软件工程师。作为机密计算工作组的成员,她为 GPU 机密计算开发 CUDA 驱动程序和运行时。在她 18 年的硬件和软件工程领导职位中,她跨 NVIDIA SOC 和 GPU 的几代架构和设计了许多硬件和软件功能和流程。
Vidhya Krishnan 是一位杰出的架构师,也是 NVIDIA GPU 机密计算的首席硬件架构师。她的职业生涯大部分时间都在从事 GPU 的工作。她对机密计算作为一项技术充满热情,并期待它成为默认的部署模式。
Aruna Manjunatha 是 NVIDIA GPU 软件团队的系统软件工程总监。她已经在内核模式驱动程序软件团队工作了近 15 年,负责将新的 GPU 系列从设计推向生产。她最近的角色是担任 GPU 机密计算的软件工程主管。她热衷于指导和辅导,她认为这是向他人学习的好方法。
Rob Nertney 是 CUDA 的高级技术产品经理。他花了近 15 年的时间为内部和外部开发人员构建加速器硬件的功能和部署到超大规模环境中的架构。他在与当今生产中的安全解决方案相关的处理器设计方面拥有多项专利。在业余时间,天气好的时候他喜欢打高尔夫球,天气不好的时候他喜欢玩游戏(当然是在 RTX 硬件上)。
Michael O’Connor 是 NVIDIA 的系统软件架构师和高级杰出工程师。他在 NVIDIA 工作了近 10 年,主要专注于深度学习框架(如 PyTorch、TensorFlow 和 MXNet)的 GPU 优化。一年前,他加入了机密计算团队,专注于证明和整体工作流程。
Phil Rogers 是 NVIDIA 的计算服务器软件架构师和系统软件副总裁。他是 NVIDIA 多个项目的软件负责人,包括机密计算、Fleet Command、NVIDIA 认证系统、整个堆栈的长期支持和 NGC。Phil 对加速计算的各个方面充满热情,包括易用性、性能、可扩展性和安全性。
版权所有 © 2023 归所有者/作者所有。出版权已许可给 。
最初发表于 Queue 第 21 卷,第 4 期—
在 数字图书馆 中评论本文
Jinnan Guo、Peter Pietzuch、Andrew Paverd、Kapil Vaswani - 使用机密联邦学习的可信 AI
安全性、隐私性、问责制、透明度和公平性原则是现代 AI 法规的基石。经典 FL 的设计非常强调安全性和隐私性,但以透明度和问责制为代价。CFL 通过将 FL 与 TEE 和承诺相结合,弥补了这一差距。此外,CFL 还带来了其他理想的安全属性,例如基于代码的访问控制、模型机密性以及推理期间的模型保护。机密容器和机密 GPU 等机密计算的最新进展意味着现有的 FL 框架可以无缝扩展以支持具有低开销的 CFL。
Raluca Ada Popa - 机密计算还是密码计算?
通过 MPC/同态加密与硬件飞地进行安全计算,在部署、安全性和性能方面存在权衡。关于性能,您想到的工作负载非常重要。对于简单的求和、低阶多项式或简单的机器学习任务等简单工作负载,这两种方法都可以在实践中使用,但对于复杂的 SQL 分析或训练大型机器学习模型等丰富的计算,目前只有硬件飞地方法在许多实际部署场景中足够实用。
Matthew A. Johnson、Stavros Volos、Ken Gordon、Sean T. Allen、Christoph M. Wintersteiger、Sylvan Clebsch、John Starks、Manuel Costa - 机密容器组
此处介绍的实验表明,Parma(在 Azure 容器实例上驱动机密容器的架构)增加的额外性能开销不到底层 TEE 增加的额外性能开销的百分之一。重要的是,Parma 确保了容器组在证明报告中扎根的所有可到达状态上的安全不变性。这允许外部第三方与容器安全通信,从而实现各种需要机密访问安全数据的容器化工作流程。公司可以在云中运行其最机密的工作流程,而无需在其安全要求上妥协,从而获得优势。
Charles Garcia-Tobin、Mark Knight - 使用 Arm CCA 提升安全性
机密计算具有巨大的潜力,可以通过将监管系统从 TCB 中移除,从而减小 TCB 的大小、攻击面和安全架构师必须考虑的攻击向量,来提高通用计算平台的安全性。机密计算需要平台硬件和软件方面的创新,但这些创新有可能增强对计算的信任,尤其是在第三方拥有或控制的设备上。机密计算的早期消费者将需要自行决定他们选择信任的平台。