如前所述，Nitro系统由三个主要部件组成：
- 专用Nitro卡
- Nitro安全芯片
- Nitro虚拟机监控程序
Nitro卡
现代EC2服务器由一个主系统板和一个或多个Nitro卡组成。系统主板包含主机CPU（Intel、AMD或Graviton处理器）和内存。Nitro卡是具有强大的64位处理能力和专用专用集成电路（ASIC）的专用硬件组件，独立于运行所有客户计算环境（包括代码和数据处理操作）的系统主板运行。
Nitro卡实现了EC2服务用于提供和管理计算、内存和存储的所有面向外部的控制接口。它们还提供所有I/O接口，例如提供软件定义的网络、Amazon EBS存储和实例存储所需的接口。这意味着，在主系统板之外与EC2服务的外部世界交互的所有组件，无论是逻辑上入站还是出站，都在独立的计算设备上运行，这些设备在物理上与运行客户工作负载的系统主板分离。
Nitro系统设计用于在主机组件和Nitro卡之间提供强大的逻辑隔离，两者之间的物理隔离提供了一个牢固可靠的边界，有助于实现该设计。虽然在逻辑上隔离且物理上独立，但Nitro卡通常包含在与主机系统主板相同的物理服务器机柜中，并共享其电源及其PCIe接口。
笔记
对于EC2 mac1.metal和mac2.metal实例。一个Nitro控制器与一个Mac Mini在同一个金属外壳中，两者通过Thunderbolt连接在一起。请参阅Amazon EC2 Mac实例。
Nitro卡的主要组件是AWS设计的运行专用固件的片上系统（SoC）包。AWS已仔细推动了这些卡的硬件和固件的设计和实现过程。硬件由负责AWS内部硅设计的团队Annapurna Labs从头开始设计。这些卡的固件由专门的AWS工程团队开发和维护。
笔记
Annapurna实验室于2015年被亚马逊收购，此前在AWS Nitro系统关键技术开发的初始阶段成功建立了合作伙伴关系。Annapurna不仅负责制造AWS Nitro系统硬件，还负责AWS定制的基于Arm的Graviton处理器、用于ML训练和推理的AWS Trainium和AWS Infrentia硬件加速器芯片、AWS NitroSSD和用于Amazon Redshift的Aqua（高级查询加速器）。
Nitro卡上的关键控制固件可以使用加密签名软件包实时更新。Nitro卡可以独立于Nitro系统的其他组件进行更新，包括彼此以及系统主板上的任何可更新组件，以便部署新功能和安全更新。Nitro卡的更新对客户的工作负载几乎没有影响，也没有放松Nitro系统的任何安全控制。
Nitro卡通过PCIe物理连接到系统主板及其处理器，但在逻辑上与运行客户工作负载的系统主板隔离。Nitro系统可以包含一个或多个Nitro卡；如果有多个，则通过服务器机柜内的内部网络进行连接。该网络提供了独立于系统主板的Nitro卡之间的专用通信信道，以及与基板管理控制器（BMC）的专用连接（如果服务器设计中存在）。
Nitro控制器
主要的Nitro卡称为Nitro控制器。Nitro控制器为整个系统提供硬件信任根。它负责管理服务器系统的所有其他组件，包括加载到系统其他组件上的固件。整个系统的固件存储在直接连接到Nitro控制器的加密固态驱动器（SSD）上。SSD的加密密钥设计为受可信平台模块（TPM）和SoC的安全引导功能的组合保护。本节介绍了Nitro控制器的安全引导设计及其作为服务器和网络之间的可信接口的作用。
笔记
在AWS前哨部署的情况下，Nitro安全密钥也与TPM和SoC的安全引导功能一起使用，以保护直接连接到Nitro控制器的SSD的加密密钥。
Nitro控制器安全引导设计
Nitro控制器中SoC的安全引导过程从其引导ROM开始，然后通过测量和验证存储在连接到Nitro Controller的闪存中的早期固件来扩展信任链。随着系统初始化的进行，使用可信平台模块（TPM）记录初始启动代码测量值，然后将测量值扩展到其他系统固件。嵌入防篡改TPM中的加密密钥用于对已知良好系统测量的完整集合进行数字签名。然后在每次重新启动时，将此数字签名文件与所有后续系统测量值进行比较，以检测任何意外更改。
如果未检测到任何更改，则使用由TPM中锁定的密钥加密的附加解密密钥来解密系统中的附加数据，以允许引导过程继续。如果检测到更改，则不会解密附加数据，系统将立即停止服务，因此不会托管客户工作负载。
前面的步骤详细说明了Nitro控制器在启动时建立系统软件完整性和有效性的过程。为了使安全引导设计真正安全，SoC引导代码的每个阶段不仅必须有效且未修改，而且必须在实现时功能正确。这一点尤其适用于作为设备物理制造一部分的静态ROM代码。为此，AWS在我们的设计中应用了正式的方法来验证早期启动代码的内存安全属性。
Nitro控制器作为EC2服务器和网络之间的接口
Nitro Controller是EC2、Amazon EBS和Amazon虚拟私有云（Amazon VPC）的物理服务器和控制平面之间的专用网关。虽然逻辑上不同，并且由多个子组件微服务组成，但这三个控制平面在下文中通常称为EC2控制平面。
笔记
在AWS中，一种常见的设计模式是将系统分成负责处理客户请求的服务（数据平面）和负责管理和销售客户配置的服务（例如，创建、删除和修改资源）（控制平面）。Amazon EC2是包括数据平面和控制平面的架构的示例。数据平面由运行客户EC2实例的EC2物理服务器组成。控制平面由许多服务组成，这些服务负责与数据平面通信，并执行诸如中继命令以启动或终止实例或接收操作遥测等功能。
Nitro系统控制架构
Nitro控制器向专用EC2控制平面网络提供一组经过严格认证和加密的网络API，用于系统管理。每一个API操作都会被记录，所有调用API的尝试都会使用细粒度访问控制模型进行加密认证和授权。每个控制平面组件仅被授权用于完成其业务目的所需的一组操作。使用正式方法，我们已经证明Nitro控制器的控制消息解析实现的面向网络的API在面对任何配置文件和任何网络输入时都不会出现内存安全错误。
用于I/O的Nitro卡
除Nitro控制器外，一些系统还使用其他专用Nitro卡来执行特定功能。这些从属Nitro卡与Nitro控制器共享相同的SoC和基本固件设计。这些Nitro卡根据其特定功能的需要设计了附加硬件和专用固件应用程序。例如，包括用于VPC的Nitro卡、用于EBS的Nitro卡和用于本地NVMe存储的NitroCard。
这些卡使用集成在SoC中的安全密钥存储的硬件卸载引擎实现网络和存储的数据加密。这些硬件引擎提供本地NVMe存储和远程EBS卷的加密，而不会对其性能产生实际影响。VPC的Nitro Card的最后三个版本（包括所有新发布的实例类型上使用的版本）对所有VPC流量进行透明加密，使其能够传输到运行在同样配备加密兼容Nitro卡的主机上的其他EC2实例，而不会影响性能。
笔记
AWS在所有类型的EC2实例之间提供安全的私有连接。此外，一些实例类型使用底层Nitro系统硬件的卸载功能，使用AES-256-GCM自动透明地加密和匿名化实例之间的传输流量。对网络性能没有影响。为了支持实例之间的这种额外的传输流量加密，实例必须是支持的实例类型，在同一个Region中，并且在同一VPC或对等VPC中。流量不得通过虚拟网络设备或服务，如负载平衡器或传输网关。有关其他信息和支持的实例类型列表，请参阅传输中的加密。
用于EBS、本地实例存储和VPC网络的加密密钥仅以明文形式存在于Nitro卡的受保护易失性存储器中；AWS操作员以及在主机系统主处理器上运行的任何客户代码都无法访问它们。Nitro卡提供通过PCIe连接到主服务器处理器NVMe的硬件编程接口，用于块存储（EBS和实例存储）、用于网络的弹性网络适配器（ENA）、用于带外操作系统控制台日志记录和调试的串行端口等。
笔记
EC2为客户提供了访问实例控制台输出以进行故障排除的权限。Nitro系统还使客户能够连接到串行控制台会话，以便对引导、网络配置和其他问题进行交互式故障排除。在此上下文中，“带外”是指客户通过与实例本身或其网络连接分离的通道获取信息或与其实例交互的能力。
当系统配置为使用Nitro Hypervisor时，Nitro卡提供的每个PCIe功能都使用单根输入/输出虚拟化（SR-IOV）技术细分为虚拟功能。这有助于将硬件接口直接分配给VM。客户数据（客户传送给我们用于处理、存储或托管的内容）直接在Nitro卡提供的实例和这些虚拟化I/O设备之间移动。这将使I/O中涉及的软件和硬件组件集最小化，从而降低成本、提高性能和提高安全性。
Nitro安全芯片
Nitro控制器和其他Nitro卡一起作为Nitro系统中的一个域运行，系统主板与Intel、AMD或Graviton处理器一起运行，客户工作负载运行在该主板上。虽然Nitro控制器及其安全引导过程为Nitro系统提供了硬件信任基础，但使用了一个附加组件来扩展对系统主板的信任和控制。Nitro安全芯片是这两个域之间的链接，它将Nitro控制器的控制扩展到系统主板，使其成为系统的从属组件，从而扩展了Nitro Controller的信任链以覆盖它。以下各节详细介绍Nitro控制器和Nitro安全芯片如何共同工作以实现这一目标。
系统硬件的Nitro安全芯片保护
Nitro安全芯片是集成到服务器系统主板中的设备。在运行时，它拦截并调节对本地非易失性存储设备和低速系统管理总线接口（如串行外围接口（SPI）和I2C）的所有操作，换句话说，对所有固件的操作。
Nitro安全芯片也位于BMC和主系统CPU之间的高速PCI连接上，这使得该接口能够在生产系统上进行逻辑防火墙。Nitro安全芯片由Nitro控制器控制。因此，Nitro控制器通过其对Nitro安全芯片的控制，能够调解和验证系统主板或Nitro卡上固件的更新或其他非易失性设备的编程。
一种常见的行业实践是依靠管理程序来保护这些系统硬件资产，但当不存在管理程序时，例如当EC2以裸机模式使用时，需要一种替代机制来确保用户无法操作系统固件。Nitro安全芯片提供关键的安全功能，确保主系统CPU不能在裸机模式下更新固件。此外，当Nitro系统与Nitro Hypervisor一起运行时，Nitro安全芯片除了为管理程序提供的系统硬件资产提供保护外，还提供深度防御。
系统启动或重置时的Nitro安全芯片
Nitro安全芯片还在系统启动或重置期间提供第二个关键安全功能。它控制服务器系统主板的物理复位引脚，包括其CPU和BMC（如果存在）。这使Nitro控制器能够完成自己的安全引导过程，然后在指示Nitro安全芯片释放主CPU和BMC以使其不被重置之前，验证基本输入/输出系统（BIOS）、BMC和所有其他系统固件的完整性。只有这样，CPU和BMC才能使用刚刚通过Nitro控制器验证的BIOS和固件开始启动过程。
Nitro虚拟机监控程序
Nitro Hypervisor是一个有限的、精心设计的组件，已被有意地最小化，并专门构建，具有执行其指定功能所需的功能，不再需要。Nitro Hypervisor被设计为接收从Nitro控制器发送的虚拟机管理命令（启动、停止等），并通过PCIe将Nitro硬件接口（用于EBS和实例存储的NVMe块存储、用于网络的弹性网络适配器（ENA）等）提供的SR-IOV虚拟功能分配给适当的VM。
笔记
虽然Nitro体系结构的独特之处在于它不需要使用管理程序来提供软件定义的基础架构，但在大多数客户场景中，虚拟化是非常有价值的，因为它允许将非常大的服务器细分为多个实例（VM）同时使用，以及其他优势，如更快的资源调配。虚拟化配置中需要Hypervisor，以提供来宾和系统的隔离、调度和管理。因此，在这些常见场景中，Nitro Hypervisor在保护基于Nitro的EC2服务器方面发挥着关键作用。
在Nitro系统上构建的一些实例类型包括硬件加速器，它们都由AWS和第三方（如图形处理单元或GPU）构建。Nitro Hypervisor还负责将这些硬件设备分配给VM，从硬件错误中恢复，并执行无法通过带外管理接口执行的其他功能。
在Nitro Hypervisor中，根据设计，没有网络堆栈，没有通用文件系统实现，也没有外围设备驱动程序支持。Nitro Hypervisor的设计仅包括其任务所需的服务和功能；它不是一个通用系统，既不包括外壳，也不包括任何类型的交互式访问模式。与常规管理程序相比，Nitro管理程序的体积小且相对简单，这本身就是一个显著的安全优势。
Nitro Hypervisor代码是一个托管的、加密签名的类似固件的组件，存储在连接到Nitro控制器的加密本地存储上，因此链接到Nitro控制器的硬件信任根。当系统配置为使用Nitro虚拟机监控程序时，Nitro控制器以类似于固件的方式将虚拟机监控代码的已知良好副本直接加载到系统主板上。
笔记
此虚拟机监控程序注入过程的机制是使用Nitro控制器提供给主板的只读NVMe设备作为系统引导驱动器。
将数据处理和I/O虚拟化卸载到分立硬件，并减少在主机CPU上运行的管理程序的责任，这是Nitro系统设计的核心。它不仅通过隔离提供了改进的性能和更强的安全性，还支持EC2的裸机实例类型功能，因为管理程序现在是一个可选的分立组件，不再需要它来提供I/O虚拟化、系统管理或监视。
笔记
Nitro系统通过在Nitro卡上而不是在主机的系统主板CPU上运行虚拟化系统的几乎所有功能，实现了有效的“裸机”性能。请参阅AWS Nitro系统的裸金属性能。
Nitro Hypervisor对非必要功能的严格排除消除了其他Hypervisor可能遭受的各种错误，例如远程网络攻击或基于驱动程序的权限升级。即使Nitro Hypervisor中存在允许访问特权代码的错误，但由于缺少标准操作系统功能（如交互式shell、文件系统、通用用户空间实用程序、，或获得可促进较大基础设施内横向移动的资源。
例如，如前所述，Nitro Hypervisor没有网络堆栈，也无法访问EC2网络。相反，Nitro控制器和其他Nitro卡调解对外部网络的所有访问，无论主服务器处理器是运行Nitro Hypervisor还是以裸机模式运行。此外，正如下面详细讨论的，Nitro的被动通信设计意味着任何试图从在管理程序环境中运行的代码到Nitro卡的“扩展”都将被拒绝和警告。
Nitro Hypervisor的更新过程
维护系统安全的一个关键方面是例行更新。Nitro Hypervisor允许全系统实时更新。当Nitro Hypervisor的新版本可用时，将替换完整运行的Hypervisor代码，同时保留客户EC2实例，对这些实例的性能几乎没有影响。这些更新过程的设计使得任何时候都不需要放弃或放松Nitro系统的任何安全协议或防御。此整体实时更新功能旨在为客户的实例提供零停机时间，同时确保不仅可以定期快速应用新功能，还可以快速应用安全更新。
客户实例停机时间与Nitro系统组件更新的分离消除了EC2服务在计划系统更新时仔细权衡客户体验和潜在安全影响之间的需要，从而提高了安全性。
