在安全世界中使用虚拟化进行隔离 --Armv8.4 上的安全世界软件架构_arm spm

本文翻译自文档Isolation using virtualization in the Secure world

一、简介

Armv8.4 架构在安全世界中增加了虚拟化支持。本白皮书介绍了引入此功能的原因以及它提供的安全性改进。本文介绍了一种利用这些优势的软件架构。安全 EL2 和此软件架构为平台安全架构 (PSA) 固件框架的 A-Profile 处理器版本提供了基础。

二、背景--Arm TrustZoneTM 的简史

Arm TrustZone 于 2003 年被引入 Arm 架构 A-profile。TrustZone 方法的核心是硬件分离的安全和正常世界的概念。安全硬件资源只能由运行在安全世界中的软件访问。普通世界中的软件被硬件阻止访问这些资源。安全（可信）和正常（不可信）世界的概念延伸到处理器之外，包括 SoC 内的内存、软件、总线事务、中断和外围设备。

TrustZone 的引入为可信操作系统 (OS) 供应商的生态系统铺平了道路。最初，可信操作系统提供基本设备安全服务，例如可信启动或平台机密处理。如今，受信任的操作系统已经发展到支持定制应用程序，这些应用程序可能会在许多安全用例中使用，例如安全支付或媒体保护。

最初，受信任的操作系统占据了与 TrustZone 相关的所有处理器模式，包括专门用于在正常和安全世界之间切换的代码，以及提供安全服务的代码。在基于 Armv7 和先前架构修订版的系统中，切换代码以监控模式运行，而服务代码以安全监督模式和安全用户模式运行。在 Armv8 监控模式中演变为异常级别 EL3，具有自己的内存转换机制和中断向量。这允许更清晰的代码分离，更容易为切换和服务提供单独的二进制图像。

EL3 的出现，为标准化关键平台管理功能提供了新的机会。在那之前，这些都是在 Normal 中实现的世界软件，导致碎片化，解决方案必须针对每个操作系统和每个单独的平台重复。添加异常级别使得为这些管理功能提供标准固件解决方案成为可能，消除了正常世界操作系统中的碎片和通用代码。该服务最普遍的例子是电源管理。这些标准化工作产生了一些关键规范：

SMC 调用约定 (SMCCC) 本文档提供了从安全世界请求服务时要遵循的标准方法。它描述了如何将寄存器用于参数和返回值，以及如何调用安全监视器调用 (SMC) 指令。

电源状态协调接口 (PSCI) 系统和处理器电源管理的标准，涵盖许多用例，包括启动、热插拔、空闲以及系统关闭和重置。

软件委托异常接口 (SDEI) 主要用于企业系统，该规范提供了等效于不可屏蔽中断的软件。

这种标准化势头并没有止步于规范，它还包括 Trusted Firmware 开源项目，以前称为 Arm Trusted Firmware 项目。可信固件实现了上述规范，并为可信启动提供了参考。如今，该项目为大多数 Arm 供应商提供了 Secure world 固件基础，并支持许多流行的可信操作系统。除了上述规范之外，可信固件还可用于提供其他服务，例如勘误表管理或芯片供应商特定服务。

图 1 显示了基于 Armv8-A 架构的当今系统中安全世界提供的各种服务。该图还显示了提供这些服务的软件代理以及按异常级别进行的广泛分区。受信任的操作系统提供安全服务。这通常跨越Secure EL1 和 Secure EL0。服务通常通过在Secure EL0 中运行的受信任应用程序提供。为了支持这些服务，受信任的操作系统将具有受信任硬件资源的驱动程序，例如安全加密加速器或安全存储设备。EL3 除了托管代码以在 Normal 和 Secure 世界之间转换之外，还提供平台服务，例如通过 PSCI 进行的核心电源管理。此代码由芯片供应商平台固件提供，通常基于 Trusted Firmware 开源项目的代码。

三、当今安全世界面临的挑战

TrustZone 的成功也带来了一些架构挑战，如下几节所述。

3.1 可信应用生态系统挑战

TrustZone 的成功催生了许多来自不同供应商的可信操作系统。尽管它们提供了类似的服务，并且有一些围绕可信操作系统 API 的标准，但可信应用程序是特定于可信操作系统的。这在图 1 中进行了说明，它显示了普通世界客户端应用程序和受信任的应用程序如何需要链接到受信任的操作系统供应商特定库。这限制了应用程序从一个受信任的操作系统到另一个的可移植性范围。移植成本意味着应用程序往往与特定的受信任操作系统相关联。

这给 OEM 带来了一个问题，他们需要发布一组丰富的应用程序，不同的应用程序与不同的受信任操作系统相关联。

虽然在 Secure EL1 中有托管多个受信任操作系统的方法，但这需要对受信任操作系统进行修改，以及不同受信任操作系统供应商之间的协作。

3.2 在安全世界中集成来自多个供应商的代码

受信任的操作系统需要访问受信任的硬件资源以提供其服务。在某些情况下，这是通过硅供应商驱动程序提供的，需要将其集成到受信任的操作系统中。在其他情况下，芯片供应商会提供自己的可信操作系统，这再次导致 OEM 陷入他们可能需要集成多个可信操作系统的境地。这两种方法都要求 OEM 集成来自不同供应商的资源。

如上所述，除了安全服务外，平台服务将由 EL3 中的平台固件提供。这些服务需要硅供应商特定代码来执行功能，例如电源管理。与这些服务一起运行的是调度程序代码，它涉及将 SMC 调用调度到一个或多个受信任的操作系统以及硅供应商固件。调度代码包括受信任的操作系统特定代码，以及通常源自受信任固件项目的通用代码。

图 1 说明了由上述考虑产生的示例软件堆栈。可以看出，有许多供应商参与其中。构成此图景的关键安全世界软件组件和供应商是：

• 支持应用程序安全服务的可信操作系统。由一个或多个第三方受信任的操作系统供应商提供。

• 受信任的操作系统或驱动程序模型，以支持平台上受信任的硬件资源，例如安全存储或安全元件。由硅供应商提供。

• EL3 固件提供平台服务，例如 PSCI。由硅供应商提供。

• EL3 固件提供在正常世界和适当的安全世界有效载荷之间的切换，其来源可以来自不同的供应商。

3.3 最小特权原则

最小特权原则要求组件必须能够仅访问其正确操作所必需的信息和资源。这与当前的安全世界软件方法形成对比，如图1 所示。EL3 和安全 EL1 是特权异常级别，在 Armv8.3 或更早版本上，它们对系统地址映射和物理中断的访问级别相同。这意味着无法将运行在 EL3 固件中的组件与运行在安全 EL1 中的组件隔离开来。特别是：

EL3 中的固件不能与受信任的操作系统隔离。在 EL3 中运行的固件不能限制安全和非安全系统的可见性来自安全 EL1 中受信任操作系统的地址映射。

EL3 固件组件不能相互隔离。如图 1 所示，通用固件组件、芯片供应商或第三方受信任的操作系统供应商组件可以合并到 EL3 中。所有这些都来自不同的供应商，但不能相互隔离，因为它们对物理地址映射和物理中断具有相同的可见性。

在安全的 EL1 中，无法保护正常世界免受受信任的操作系统的影响。Secure EL1 可以不受限制地访问整个物理地址映射，包括安全的和非安全的。对系统地址映射的无限制访问已被用于对一些受信任的操作系统实现的权限提升攻击。

总的来说，这些限制使得对每个软件组件强制执行最小特权原则成为不可能。这增加了审计和认证的复杂性，因为所有软件实体都需要相互隐式信任，因此不能单独进行审计。这种方法还使得难以将受信任的硬件资源隔离到特定的软件实体。系统 MMU (SMMU) 可以缓解这个问题，但它并不能消除它，因为对 SMMU 进行编程的软件组件不能与其他安全世界软件组件隔离。

3.4 所需的解决方案

解决上面列出的挑战需要一个可以促进组件化和硬件隔离的架构。该解决方案需要从仅提供两个世界之间隔离的TrustZone 提供的安全隔离扩展到可以在多个互不信任的软件映像之间提供隔离的架构。特别是，该解决方案需要：

• 一种在软件组件之间提供硬件隔离的方法。这消除了相互信任的需要，并允许对组件进行单独审计。

o 隔离需要限制对物理地址空间、寄存器、处理器和支持直接内存访问 (DMA) 的可信外围设备的访问。

• 为了使供应商的生态系统能够协同工作，该架构将需要标准 API 来实现公共边界。

o 标准 API 将使各种软件映像能够进行通信，并允许代码的泛化和组件化。这可以从 EL3 和非安全 EL2 中删除受信任的操作系统供应商特定代码。

四、安全世界中的虚拟化

Armv8.4 架构引入了 Secure EL2 扩展，增加了对安全世界中虚拟化的支持。这将在非安全状态下可用于虚拟化的功能带入安全状态。

虚拟化支持的一个关键特性是添加了由管理程序控制的第二阶段转换。这允许管理程序控制哪些物理内存区域可用于虚拟机。图 2 说明了基本思想。客户操作系统控制转换的第一阶段，在虚拟地址空间 (VA) 和中间物理地址空间 (IPA) 之间进行转换。第二阶段的翻译，由管理程序控制，在 IPA 和物理地址空间 (PA) 之间进行转换。这使管理程序能够控制物理地址空间的哪些部分对给定的虚拟机可见。

图 2 阶段 2 转换

Secure EL2 将阶段 2 转换添加到处理器的安全状态。此外，Arm System MMU 架构 3.2 及更高版本支持在安全状态下为其他 IO 主控器进行阶段 2 转换。这些特性共同为安全世界带来了虚拟化支持，并提供了满足上述许多架构要求的硬件基础。安全虚拟化可实现：

1. EL3 软件与 Secure EL1 软件的隔离。

2. Normal world 软件与 Secure EL1 软件的隔离。

3. 将不同的 Secure EL1 软件组件相互隔离。

Secure EL2 提供的架构扩展支持将来自不同供应商的 Secure world 软件隔离开来。这种架构还可以隔离具有不同用途的软件堆栈。

传统上，受信任的操作系统可以访问系统地址图中的任何位置。由于受信任的操作系统是一个特权实体，因此可以利用其实现中的弱点来访问系统中的任何内存地址，无论是安全的还是非安全的。事实上，这种性质的特权升级攻击已经在一些受信任的操作系统实现上报告过了。Secure EL2 通过限制可访问的内存区域来防止这种升级软件驻留在 Secure EL1 或Secure EL0 中。这是通过使用第 2 阶段翻译来实现的。在系统 MMU的安全状态下控制第 2 阶段转换，将这种保护扩展到包括支持 DMA 的可信硬件资源。

五、安全分区

Secure EL2 和 SMMU 提供了应对上述挑战所需的硬件隔离。本节描述了一种利用这些特性来应对这些挑战的软件架构。该架构还建立了标准 API，支持安全世界软件供应商之间的协作。

图 3 具有安全分区的软件堆栈

图 3 描述了在包含 Secure EL2 的系统中，用于安全世界的软件架构的基本元素。基本元素是：

Secure EL1 中的安全分区。安全分区是一个沙盒环境，具有独立的地址空间。该空间不能被其他安全分区直接访问。使用 Secure EL2，安全分区是通过虚拟化支持实现的，本质上是一个安全世界虚拟机。安全分区可用于托管受信任的操作系统，或者可能包含受信任硬件资源的驱动程序堆栈。图 3 描绘了一个托管可信操作系统的安全分区，以及另一个托管硅供应商提供的平台驱动程序的安全分区。

安全分区管理器。EL3 和 Secure EL2 中的通用固件负责管理这些安全分区。这里的一个关键组件是安全分区管理器(SPM)，它负责将请求引导到正确的安全分区，并负责监管安全分区的访问。SPM 可以被认为是一个最小的分区管理程序。

图 3 说明了一种软件架构，其中由芯片供应商提供的特定于平台的固件组件与 Secure EL2 和 EL3 中的固件以及受信任的操作系统隔离。这是通过将受信任的操作系统和平台固件放入单独的安全分区来实现的。要启用此架构，SPM 需要知道每个分区需要哪些资源。这允许它设置适当的内存映射限制，并在向分区发送消息或中断时调度分区。这可以通过对每个分区使用资源描述清单来实现，该清单主要描述：

1. 它需要的系统资源、内存、中断的所有权以及对物理系统地址映射中区域的访问。

2. 它通过请求的资源和指定属性的组合实现的安全服务列表。

在启动时，SPM 使用资源描述来：

1. 验证和分配安全分区请求的资源。

2. 执行安全分区所需的架构和系统设置，例如维护 vGIC 和第 2 阶段转换。

3. 一旦建立了执行环境，就初始化安全分区。

为了保持 EL3 和安全 EL2 代码的通用性，该软件架构将需要在各种软件代理之间的边界处使用标准 API。普通世界中的安全服务客户端和安全分区中的服务提供者之间需要 API。这种接口所需的功能是：

1. 启用普通世界中的客户端和安全分区中的服务之间的消息传递。

2. 启用分区中安全服务的发现。

3. 启用客户端和安全分区之间的内存共享。

4. 在普通世界管理程序和 SPM 中不需要受信任的操作系统特定驱动程序的通用接口，因此需要 EL3 和安全 EL2。

Arm 对该接口的提议在安全分区客户端接口 (SPCI) 中进行了描述。Arm 欢迎对此提案的合作和反馈。

此外，安全分区和安全分区管理器之间需要标准 API。这为安全分区运行环境提供了基础。这种 API 的基本要求：

1. 启用安全分区之间的消息传递。

2. 在安全分区中启用消息和中断的接收。

3. 启用安全分区的初始化。

与资源管理一起，安全分区之间的消息传递提供了一种为安全世界客户端创建服务的方法，以及安全共享受信任的硬件资源的方法。Arm 提出了安全分区运行时 (SPRT)，作为安全分区运行时 API 的基础。该规范描述了安全分区可以依赖的运行时模型来实现安全服务。它指定了必须包含在安全分区的资源描述中的强制性信息，以及运行时模型和到 SPM 的接口。SPRT和 SPCI 可以被认为是 A-profile 处理器中平台安全架构的固件框架。这两个规范都涵盖了具有和不具有 Secure EL2 (S-EL2) 的系统的方法。这使软件能够在S-EL2 硬件可用之前迁移到这些规范。

六、安全生态系统向Secure EL2的迁移

上述软件架构为 Secure world 软件的供应商带来了变化和影响。这些将在下面讨论。

6.1 对可信操作系统的影响

虚拟化可信操作系统会改变它们与平台上物理资源交互的方式。SPM 限制对系统地址映射和物理中断的访问。

在没有 Secure EL2 的系统中，安全物理中断通常被路由到 Secure EL1。使用 Secure EL2，中断由安全固件以类似于正常世界中的管理程序管理非安全物理中断的方式进行管理。这些首先针对管理程序，然后将其对应的虚拟中断委托给来宾操作系统 VM。为了在提议的安全 EL2架构中启用这种方法，系统集成商需要为安全分区中的给定可信操作系统指定它将处理哪些安全中断。安全分区管理器需要使用此信息，以便它可以将相应的虚拟中断路由到适当的安全分区。受信任的操作系统中断处理代码不应受此显着影响。受信任的操作系统将针对软件透明的虚拟 GIC (vGIC) 运行，并在中断向量处接收中断。

与中断情况一样，系统集成商必须指定安全分区可以看到哪些区域或内存。SPM 需要使用此信息，以便它可以在处理器中放置适当的第 2 阶段页表，如果需要，在系统 MMU 中放置。

将受信任的操作系统放置在安全分区中，将需要进行一些更改以启用新标准 API 的使用。

6.2 对普通世界软件的影响

Hypervisor 可用于移动设备以提供额外的安全性。在这种情况下，管理程序可能需要对受信任的操作系统进行特定修改，以允许客户端操作系统将消息发送到受信任的操作系统。

对于图 3 中提出的架构，Arm 提出了一个通用的消息传递接口，即安全分区客户端接口 (SPCI)。这将允许从 EL3 和安全 EL2 固件中删除受信任的操作系统特定驱动程序。它将导致由Trusted Firmware 开源项目提供的 SPM 的通用实现。迁移到 SPCI 将需要更改客户端内核中的受信任操作系统驱动程序以迁移到 SPCI，并在普通世界的虚拟机管理程序中提供通用驱动程序。

七、结论

本白皮书描述了在 Armv8.4 架构的安全世界中引入虚拟化扩展的基本原理。此外，它提出了一种扩展现有安全世界软件架构以利用安全虚拟化优势的方法。这些好处包括改进的安全隔离，以及普通和安全世界代码的泛化。可以在 SPCI 和SPRT 规范中找到对该架构的更详细描述。这些规范以及在架构中引入安全 EL2为 A-Profile 处理器的平台安全架构 (PSA) 固件框架提供了基础。

八、术语汇编