Google最近在Google云平台（GCP）上推出了gpu，这将允许客户利用这种硬件实现高度并行的工作负载。这些GPU通过各种PCIe交换机连接到我们的云机器，这要求我们对PCIe安全有深入的了解。

保护PCIe设备需要克服一些固有的挑战。例如，GPU在过去几十年中变得更加复杂，开辟了新的攻击途径。由于gpu被设计成直接访问系统内存，而且硬件在历史上被认为是可信的，因此很难确保将其包含的所有设置都被准确设置，也很难确保这些设置是否工作。而且由于GPU制造商没有为GPU的主要进程提供源代码或二进制文件，我们无法通过检查这些来获得更多的信心。您可以在这里阅读更多关于PCI和PCIe规范带来的挑战。

由于受到威胁的PCIe设备存在恶意行为的风险，谷歌需要制定一个计划来应对这些类型的攻击，特别是在云服务和公开可用虚拟机的世界中。我们的方法一直专注于缓解：确保受损的PCIe设备不会危及计算机其余部分的安全。

解救模糊

我们武器库中的一个关键武器是模糊，一种使用无效、意外或随机输入来暴露不正常行为的测试技术，如内存泄漏、崩溃，或未记录的功能。我们构建的硬件模糊器直接测试我们的云GPU使用的PCIe交换机的行为。

在我们对PCIe规范进行初步研究之后，我们准备了一份没有明确定义结果的边缘情况和设备行为列表。我们想在真正的硬件上测试这些行为，还想找出真正的硬件是否正确地实现了规范中定义良好的部分。硬件缺陷实际上很常见，但许多安全专业人员认为它们不存在，只是相信制造商。在谷歌，我们想验证每一层的堆栈，包括硬件。

我们的计划需要一个高度专业化的模糊器，设计成能够有效对抗我们在云硬件中使用的生产配置。我们在机器上使用了各种GPU和交换机组合，因此我们在类似配置中设置了一些可编程网络接口控制器（NIC）来模拟GPU内存访问。

我们的fuzzer使用这些NIC来攻击每个NIC的直接上游端口，以及网络中的任何其他可访问端口，具有多种内存读写功能。这些操作包括目标攻击、随机性和"幸运数字"的混合，它们往往会在许多硬件架构上造成问题。我们希望检测由于模糊化而对任何端口的配置所做的更改，特别是端口的辅助和从属总线号。启用源验证的PCIe网络主要由这些总线号控制，这些总线号指示数据包可以和不能去哪里。能够重新配置端口的辅助或从属总线号可以让您访问应被禁止的PCIe网络部分。

我们的安全团队审查了任何可疑的内存读写，以确定它们是否代表安全漏洞，并相应地调整了模糊器或PCIe设置。

我们发现了一些奇怪之处。例如，在一个不正确的配置上，交换机上一些未记录的调试寄存器被错误地暴露给下游设备，我们发现在某些访问模式下，这可能会导致交换机发生严重故障。如果一个设备能在它所连接的交换机中引起不符合规范的行为，它可能会引起不安全的路由，这将危及整个网络。模糊化的价值在于它能够在规范中定义的正常行为和操作集合之外的未记录和未定义的区域中发现漏洞。但在该过程结束时，我们已经确定了在云中安全运行GPU所需的最小ACS功能集合。

让我们也检查那些内存映射

当虚拟机初始化后，一组页表将来宾的物理内存映射到主机的物理内存，但GPU无法知道这些映射，因此将尝试写入错误的位置。这就是输入输出内存管理单元（IOMMU）的用武之地。IOMMU是一个页表，将GPU访问转换为DRAM/MMIO读写。它是在硬件上实现的，这减少了重新映射的开销。

这意味着IOMMU正在执行一个非常微妙的操作。它将自己的I/O虚拟地址映射到主机物理地址。我们希望验证IOMMU是否正常工作，并确保在设备运行不受信任的代码时随时启用它，这样就没有机会进行未经筛选的访问。

此外，IOMMU还有一些我们不想要的特性，比如兼容性中断。这是一种中断类型，用于支持缺少IOMMU提供的中断重新映射功能的较旧Intel平台。它们不是现代硬件所必需的，如果启用它们，来宾可以触发意外的MSI、机器重新启动和主机崩溃。

这里最有趣的挑战是防范PCIe的地址转换服务（ATS）。使用此功能，任何设备都可以声称它使用的地址已经被翻译，从而绕过IOMMU翻译。对于受信任的设备，这是一个有用的性能改进。对于不受信任的设备，这是一个很大的安全威胁。ATS可以允许受损设备忽略IOMMU并写入其不应访问的位置。