【云安全】AWS Nitro系统的安全设计 --防止侧通道的EC2方法

自成立以来，EC2一直采用保守的方法为客户设计和操作安全的多租户系统。我们的设计方法支持简单可靠的抽象，它在安全域之间提供了强大的隔离，并限制了客户之间关键系统资源的共享。AWS设计我们的系统，不仅可以针对已知的安全威胁提供纵深防御，还可以避免不具备已知实用开发技术的潜在安全问题的影响。除了我们在生产中采用的经过彻底测试和完善的安全机制外，AWS还积极参与最前沿的安全研究，以确保我们不仅保持最新状态，而且代表客户积极寻找安全问题。

在过去几年中发表的微结构侧通道领域的研究和披露已经将围绕这一主题的担忧推到了最前沿。旁道是一种机制，通过对从计算机系统收集的间接数据进行分析，有可能泄露计算机系统中的秘密信息。这种间接数据的一个示例可以是系统对输入进行操作所需的时间量。在某些情况下，尽管系统从未直接披露秘密数据，但外部方可能能够通过仔细分析处理精心选择的输入所花费的时间差异来确定该秘密的价值

笔记

这种情况的一个简单示例是一个程序，它接收字符串形式的密码作为输入，并验证该字符串是否与机密值匹配。该程序一次一个字符地分析所提供的字符串，将每个字符与机密的对应字符进行比较，并在遇到不匹配时立即返回错误。尽管程序从未向请求者提供秘密的值，但对于以一个或多个与秘密相同的字符开头的输入，程序会以不同的响应时间的形式“泄漏”有关秘密的信息。通过一个系统的试错过程，观察者可以测量响应某些输入所花费的时间，以便一次确定一个字符的秘密值。

仔细部署应对措施，如AWS的开源SSL/tls实现s2n tls所采用的应对措施，可用于防止这些形式的侧信道数据泄露。

仔细部署应对措施，如AWS的开源SSL/tls实现s2n tls所采用的应对措施，可用于防止这些形式的侧信道数据泄露。

笔记

s2n-tls结合并证明了使用形式化方法的时间平衡对策，以确保过程计时受机密的影响可以忽略不计，因此攻击者可观察到的计时行为不会依赖于机密。有关s2n tls中的这些对策以及这些对策的正式证明的更多信息，请参阅SideTrail:验证密码系统的时间平衡。

微体系结构侧通道特别涉及在某些情况下对系统处理器的低级行为的操纵，以允许在该系统上运行的一个进程通过系统资源（如缓存、内部缓冲区和其他不允许直接访问的有状态数据源）间接地确定秘密数据的值。关键的是，这些副通道围绕着两个系统之间共享对低级硬件资源的访问。

AWS对EC2租户隔离采用了一种保守的方法，这将在后面的章节中讨论，其设计目的是使客户实例永远无法共享系统资源，例如L1/L2缓存或在同一CPU复合体上运行的线程。这种基本的设计选择排除了通过基于租户之间共享访问这些资源的微架构侧通道从客户实例泄漏数据的可能性。

更广泛的EC2服务中的侧通道保护

所有EC2实例都包含对侧信道的强大保护。这包括基于Nitro系统或Xen管理程序的两个实例。虽然本节讨论了Nitro系统的这些保护，但这些保护也存在于基于Xen的EC2实例中。

虚拟化EC2实例类型分为两类：

• 固定性能实例，其中CPU和内存资源在主机上的虚拟化实例的生命周期内预先分配并专用于该实例
• 突发性能实例，其中CPU和内存资源可以被过度使用，以支持在服务器上运行的大量虚拟化实例，从而为客户提供了CPU利用率低到中等的应用程序的相对实例成本。请参阅Burstable性能实例。

无论哪种情况，Nitro Hypervisor的设计和实现都包括对潜在侧通道的多重保护。

对于固定性能的实例，与其他虚拟机管理程序相比，专用资源既提供了对侧通道的自然保护，又提供了更高的性能。例如，一个c5.4xlarge实例分配了16个虚拟CPU（八个内核，每个内核提供两个线程）以及32 GiB的内存。当实例启动时，EC2控制平面指示Nitro控制器分配必要的CPU、内存和I/O资源以支持该实例。

Nitro管理程序由Nitro控制器指导，为实例分配全部物理内核和内存。这些硬件资源被“固定”到该特定实例。CPU内核不用于运行其他客户工作负载，也不以任何方式在实例之间共享任何实例内存页，这与许多管理程序不同，这些管理程序可以合并重复的数据和/或指令页以节省物理内存。

即使在资源有限的非常小的Nitro EC2实例上，CPU内核也不会通过同时多线程（SMT）在两个客户实例之间同时共享。客户实例提供了两个vCPU的倍数，对于采用SMT的处理器，代表单核的两个线程，对于使用专用全核线程的处理器配置（例如AWS Graviton处理器），代表单vCPU。不共享内核意味着不共享1级或2级缓存或其他特定于内核的资源，如推测执行或节能状态。

某些实例大小可以非同时共享某些最后一级缓存行。虽然可以将最后一级缓存线的启动和探测作为一个超低带宽信号在两个协作进程之间使用，但这与实际的侧通道不同。由于其功能，在最后一级缓存行中只引用相对较少访问的数据。侧信道通常需要非常大且统计上相关的样本数量，以克服系统中存在的噪声。

与EC2一样，当内存页不在实例之间共享时，还没有演示过实际的攻击。迄今为止，所有实用的微体系结构侧通道攻击都使用了通过SMT或共享L1/L2缓存的共享内核，或其他低级内核属性（如浮点单元）。在EC2中，侧信道攻击缓解措施非常强大，因为这些资源从未在EC2 Nitro环境中共享。

笔记

EC2准确地暴露了硬件的底层CPU拓扑，包括最后一级（通常为L3）缓存和非统一内存访问（NUMA）信息，直接传递到实例。因此，客户可以通过检查来确定分配了多大大小的实例，即“填充”共享L3缓存的一个或多个CPU段所需的CPU内核数量；从而确定给定实例是否与另一实例共享任何L3高速缓存。三级缓存共享拓扑在CPU设计之间有所不同，并且可以在核心、CPU复合体或核心复合体裸片之间共享，具体取决于处理器架构。例如，在典型的基于Intel的双插槽EC2系统中，一个大小为最大大小一半的实例将填充CPU内核，并且不会与另一个实例共享L3缓存。

如前所述，突发性能EC2实例（例如，T3、T3a和T4g）可以利用过度使用的CPU和内存资源。运行突发性能实例所需的CPU资源根据基于信用的分配进行调度。在这种低成本但相对高性能的实例系列中，即使是最小的实例类型，在使用SMT的处理器上，仍然为客户提供至少两个vCPU（一个内核，两个线程）。

然而，两个可突发性能EC2实例可以在同一内核上顺序（而不是同时）运行。物理内存页也可以作为虚拟内存页进行重用、重新映射和交换。然而，即使是可突发的实例也不会同时共享同一个内核，虚拟内存页也不会在实例之间共享。

Nitro Hypervisor在实例之间的每个上下文切换处使用了许多安全策略，以确保在同一内核上运行另一个实例之前，删除前一个实例的所有状态。这种做法对可能的侧信道攻击提供了强有力的缓解措施。

对于突发性能EC2实例，Nitro系统可以采用内存管理技术，例如将物理内存重新使用、重新映射或交换为虚拟内存页，但该系统的设计使得虚拟内存页不会在实例之间共享，以保持强隔离边界。

最后，可突发性能实例——无论是目标性能实例还是通过侧信道技术检测数据的实例——都可以在不同于以前使用的内核上重新调度，从而进一步限制任何类型基于时间的成功安全问题的可能性。

Nitro系统的附加副通道优势

除了EC2为Xen和Nitro提供的保护外，在涉及侧信道问题时，Nitro系统和NitroHypervisor的设计中还有一些不明显但非常重要的好处。例如，虽然一些管理程序需要进行大量更改以实现地址空间隔离，作为L1终端故障瞬时执行侧通道攻击缓解措施的一部分（例如，请参阅针对L1终端故障的Hyper-V HyperClear缓解措施），但Nitro系统的设计和实现提供了自然的免疫力，因为Nitro Hypervisor的虚拟地址空间与分配给客户实例的内存隔离。

我们还应用了从设计Nitro系统中学到的知识，以减轻社区版Xen管理程序中微架构侧通道攻击的新威胁。请参阅在没有直接映射的情况下运行Xen。

如前所述，Nitro系统大大减少了运行在主服务器处理器上的EC2系统代码量，这大大缩小了管理程序的攻击面，并将客户I/O数据处理与系统的其他部分隔离开来。提供EC2的软件定义I/O功能所需的AWS代码不在运行客户工作负载的处理器上运行。

专用硬件的这种划分和使用意味着I/O子系统中的客户数据处理在硬件功能级别上是隔离的，并且不驻留在主机内存、处理器缓存或其他内部缓冲区中，这与通用虚拟化软件不同，通用虚拟化软件将这些数据混合在一起，作为在共享主机CPU上运行的副作用。

所有这些保护措施的基础是AWS处于安全研究的前沿，经常领导研究和发现影响行业的问题，以及缓解和协调问题。

Nitro胶囊

Nitro Enclaves是Nitro系统的一个功能，它允许客户将其工作负载划分为独立的组件，这些组件不需要彼此完全信任，同时也是运行高度信任的代码和处理客户EC2实例管理员无法访问的数据的一种方式。本文没有介绍它的特点和优点，但以下内容值得注意。

Nitro Enclave继承了与运行在同一服务器处理器上的每个其他EC2实例相同的隔离和侧通道缓解措施。父实例必须分配固定数量的vCPU（最小数量等于一个完整内核）以及固定数量的内存页。该固定的CPU和内存资源集从父实例中减去（使用Linux和Windows内核中支持的“硬件资源热插拔”功能），然后由Nitro Hypervisor用于创建另一个完全受保护的独立VM环境，在其中运行Nitro Enclave映像。

当使用Nitro Enclaves时，上面讨论的所有保护都会自动到位，因为没有与父实例共享内核或内存。

关闭侧频道的想法

总之，Nitro和EC2平台中谨慎的设计决策提供了一系列非常有力的缓解措施，以防止实际的侧通道攻击，包括删除这些攻击所需的CPU和内存资源实例之间的共享访问。此外，客户可以选择不将其实例与属于其他客户的实例配置在同一主机上。此外，如果任何未来的研究发现新的挑战，AWS参与针对Linux、KVM、Xen和其他关键技术的协调漏洞响应小组，以及Nitro系统的实时更新技术设计，将使AWS能够快速做出反应，保护客户免受新的威胁，而不会干扰客户的工作负载。AWS是在公开披露之前从事Spectre和Meltdown项目的一小部分公司的成员，并在公开披露前减轻了其基础设施中的所有风险。

笔记

通过使用EC2的“专用实例”或“专用主机”功能，客户可以选择不与其他客户共享计算硬件。这些特性表示实例放置策略，该策略导致单个客户在任何给定时间都是唯一的客户，并且实例调度在特定的EC2物理主机上。请参阅Amazon EC2专用主机。

我们继续与Intel、AMD和ARM等关键合作伙伴合作，进行硬件安全研究和协调漏洞响应，并继续通过计算机隔离的其他创新提高标准。一个这样的例子是开源的Firecracker VMM，它使无服务器容器和基于功能的服务（如AWS Fargate和AWS Lambda）能够从虚拟化的安全性、隔离性和一致性中获益，而不会影响客户对这些工作负载所需的速度、灵活性和性能。

笔记

Firecracker是一种虚拟化技术，专门用于创建和管理安全的多租户容器和基于功能的服务。Firecracker是一种虚拟机监视器，用于管理轻量级microVM中的工作负载。它实现了一个最小的设备模型，排除了所有非必要的功能，并减少了microVM的攻击面积。除了采用的安全性和隔离优化外，Firecracker还可以在短短125ms内快速启动用户空间或应用程序代码，并为每个microVM提供低至5 MiB的内存开销。

旁道问题是一个不断发展的研究领域，并由此产生了创新和缓解措施。我们相信，依靠AWS凭借其深厚的专业知识和对这一主题的持续关注，是客户在防范未来风险方面下注的好地方。

笔记

请参阅AWS副总裁兼杰出工程师Eric Brandwine关于侧渠道问题的演示。在演讲中，他谈到了从Xen到Nitro的过渡（42.40）及其带来的优势，但也重要地指出，这一主题已经成为一个类似密码学的主题，其中最合理的方法是依赖深度专家并重用他们的工作（49.29）。