ARM A64架构TrustZone学习_arm trustzone

• 本文翻译自文档 Learn the architecture - TrustZone for AArch64

原文链接：https://developer.arm.com/documentation/102418/0101/?lang=en

一、概述

在本指南中，我们介绍了 TrustZone。TrustZone 通过内置于 CPU 中的硬件强制隔离提供了一种高效的、系统范围的安全方法。

我们涵盖了 TrustZone 添加到处理器架构中的功能、对 TrustZone 的内存系统支持以及典型的软件架构。我们还介绍了Arm 提供的资源，以帮助使用 TrustZone 的系统和软件开发人员。

在本指南的最后，您将能够：

• 给出 TrustZone 的示例用例，描述如何使用 TrustZone 来满足安全需求

• 列出 TrustZone 系统中的安全状态和物理地址空间的数量

• 说明安全监视器的用途，并举例说明需要保存或恢复的状态

• 命名典型的启用 TrustZone 的内存系统中的组件并描述它们的用途

• 解释可信基础系统架构和来自ARM的安全启动的设计规范

• 解释如何使用信任链来保护设备的安全启动

1.1 开始之前

本指南假设您熟悉Arm异常模型和内存管理。如果您不熟悉这些主题，请阅读我们的异常模型和内存管理。如果如果您不熟悉安全概念，我们还建议您阅读我们的简介阅读本指南之前，请先阅读安全指南。

二、什么是TrustZone？

TrustZone是Arm A配置文件架构中的安全架构的名称。第一在Armv6K中引入了TrustZone，Armv7-A和Armv8-A也支持TrustZones。TrustZone提供两个执行环境之间具有系统范围的硬件强制隔离，如图所示：

普通世界运行着丰富的软件堆栈。该软件堆栈通常包括一个大型应用程序集、一个复杂的操作系统（如 Linux）以及可能的管理程序。此类软件堆栈庞大而复杂。虽然可以努力保护它们，但攻击面的大小意味着它们更容易受到攻击。

可信世界运行一个更小、更简单的软件堆栈，称为可信执行环境 (TEE)。通常，TEE 包括由轻量级内核托管的多个可信服务。受信任的服务提供密钥管理等功能。该软件堆栈的攻击面要小得多，这有助于减少易受攻击的脆弱性。

注意：您有时可能会看到用于描述在普通世界中运行的软件术语丰富执行环境 (REE)。

TrustZone 旨在化圆为方。作为用户和开发人员，我们想要普通世界的丰富功能集和灵活性。同时，我们希望在受信任的世界中使用更小、更受限制的软件堆栈来实现更高程度的信任。TrustZone 为我们提供了两者，提供了两个环境，它们之间具有硬件强制隔离。

2.1 用于 ARMv8-M 的TrustZone

TrustZone 也用于引用 Armv8-M 架构中的安全扩展。虽然A profile架构和 M profile架构中的 TrustZone 之间存在相似之处，但也存在重要差异。本指南仅涵盖 A profile。

2.2 ARMv9-A 机密领域管理延伸扩展

ARMv9-A 机密领域管理延伸技术 (RME) 扩展了 TrustZone 支持的概念。本指南不包含 RME，但您可以在 Realm Management Extension Guide 中找到更多信息。

三、处理器中的 TrustZone

在本主题中，我们将讨论处理器内对 TrustZone 的支持。其他部分涵盖内存系统的支持以及基于处理器和内存系统支持的软story。

3.1 安全状态

在 Arm 架构中，有两种安全状态：安全和非安全。这些安全状态映射到什么是 TrustZone？

注意：在 Armv9-A 中，如果实现了机密领域管理延伸技术 (RME)，则有两个额外的安全状态。本指南不包括 RME 引入的更改，有关 RME 的更多信息，请参阅机密领域管理延伸技术指南。

在 EL0、EL1 和 EL2 处，处理器可以处于安全状态或非安全状态，这由 SCR_EL3.NS 位控制。您经常看到这样写：

• NS.EL1：非安全状态，异常级别 1

• S.EL1：安全状态，异常级别 1

EL3 始终处于安全状态，无论 SCR_EL3.NS 位的值如何。安全状态和异常级别的排列如下所示：

注意：对 Secure EL2 的支持最初是在 Armv8.4 - A 中引入的，并且。在 Armv8-A 中支持仍然是可选的。

3.2 在安全状态之间切换

如果处理器处于 NS.EL1 并且软件想要移动到 S.EL1，它是如何做到的？

要在任一方向更改安全状态，执行必须通过 EL3，如下图所示：

上图显示了在安全状态之间移动所涉及的步骤的示例序列。一次采取以下步骤：

1. 输入更高的异常级别需要异常。通常，此异常是FIQ 或 SMC（安全监视器调用）异常。稍后我们将更详细地了解中断处理和 SMC 。

2. 在适当的异常向量处输入 EL3。在 EL3 中运行的软件会切换SCR_EL3.NS 位。

3. 然后异常返回将处理器从 EL3 带到 S.EL1。

更改安全状态不仅仅是在异常级别之间移动和更改 SCR_EL3.NS 位。我们还必须考虑处理器状态。向量寄存器、通用寄存器和大多数系统寄存器只有一个副本。

在安全状态之间移动时，保存和恢复寄存器状态是软件而不是硬件的责任。按照惯例，执行此操作的软件称为安全监视器。这使我们之前的示例看起来更像您在下图中看到的：

可信固件是 Arm 赞助的一个开源项目，它提供了安全监视器的参考实现。我们将在本指南后面讨论可信固件。

少数寄存器由安全状态存储。这意味着该寄存器有两个副本，核心自动使用属于当前安全状态的副本。这些寄存器仅限于处理器需要始终知道这两种设置的寄存器。一个例子是 ICC_BPR1_EL1，一个用于控制中断抢占的 GIC 寄存器。银行业务是例外，而不是规则，将在您的处理器的架构参考手册中明确指出。

当存储系统寄存器时，我们使用 (S) 和 (NS) 来识别我们指的是哪个副本。

例如，ICC_BPR1_ EL1 (S) and ICC_BPR1_EL1 (NS).

注意：在 Armv6 和 Armv7 -A 中，大多数系统寄存器按安全状态存储，但通用寄存器和向量寄存器仍然很常见。

3.3 虚拟地址空间

本系列中的内存管理指南介绍了多个虚拟地址空间或转换机制的概念。例如，EL0/1 有一个翻译机制，EL2 有一个单独的翻译机制，如下所示：

安全和非安全状态也有单独的转换机制。例如，有安全 EL0/1 转换机制和非安全 EL0/1 转换机制，如下所示：

写入地址时，通常使用前缀来标识所引用的转换机制：

• NS.EL1:0x8000 - 非安全 EL0/1 转换机制中的虚拟地址 0x8000

• S.EL1:0x8000。 -在安全 EL0/1 转换机制中的虚拟地址 0x8000

需要注意的是，S.EL1:0x8000 和 NS.EL1:0x8000 是两个不同且独立的虚拟地址。处理器在安全状态下不使用NS.EL1转换，在非安全状态下不使用 S.EL1 转换。

3.4物理地址空间

除了两种安全状态外，该架构还提供两种物理地址空间：安全和非安全。在非安全状态下，虚拟地址始终转换为非安全物理地址。这意味着处于非安全状态的软件只能看到非安全资源，而永远看不到安全资源。这在此处进行了说明：

在安全状态下，软件可以访问安全和非安全物理地址空间。转换表条目中的 NS 位控制虚拟内存的块或页面转换到哪个物理地址空间，如下图所示：

注意：在安全状态下，当第一阶段 MMU 被禁用时，所有地址都被视为安全。

与虚拟地址一样，通常使用前缀来标识所引用的地址空间。对于物理地址，这些前缀是 NP: 和 SP:。例如：

• NP:0x8000 – 非安全物理地址空间中的地址 0x8000

• SP:0x8000 – 安全物理地址空间中的地址 0x8000

请务必记住，安全和非安全是不同的地址空间，而不仅仅是一个可读或可写属性。这意味着前面示例中的 NP:0x8000 和 SP:0x8000是不同的内存位置，并且被处理器视为不同的内存位置。

将地址空间视为总线上的一个额外地址位会很有帮助。

如果实施 Armv9-A 机密领域管理延伸技术 (RME)，物理地址空间的数量将增加到四个。额外的物理地址空间是 Root 和 Realm。在安全状态下运行的软件仍然只能访问非安全和安全物理地址空间。有关 RME 的更多信息，请参阅领机密域管理延伸技术指南。

3.5数据、指令和统一缓存

在 Arm 架构中，数据缓存是物理标记的。物理地址包括该行来自哪个地址空间，如下所示：

NP:0x800000 上的缓存查找永远不会命中带有 SP:0x800000 标记的缓存行。这是因为 NP:0x800000 和SP:0x800000 是不同的地址。

这也会影响缓存维护操作。考虑上图中的示例数据缓存。如果虚拟地址 va1 映射到物理地址 0x800000，当软件从非安全状态发出 DC IVAC、va1（数据或统一缓存行因虚拟地址无效）时会发生什么？

答案是在非安全状态下，所有虚拟地址都转换为非安全物理地址。因此，va1 映射到 NP:0x800000。缓存仅在包含指定地址的行上运行，在本例中为 NP:0x800000。包含 SP:0x800000 的行不受影响。

如果我们从安全状态执行相同的操作，va1 仍然映射到NP:0x800000，哪些缓存行受到影响？

与前面的示例一样，缓存使包含指定物理地址NP:0x800000 的行无效。操作来自安全状态这一事实并不重要。

是否可以通过来自非安全目标安全线路的虚拟地址执行缓存操作？

不可以。在非安全状态下，虚拟地址只能映射到非安全物理地址。根据定义，VA 从非安全状态执行的缓存操作只能针对非安全行。

对于设置/方式操作，例如 DC ISW、Xt，在非安全状态下发出的操作只会影响包含非安全地址的行。从安全状态设置/方式操作影响包含安全和非安全地址的行。

这意味着软件只能在安全状态下完全无效或清除整个缓存。从非安全状态，软件只能清理或使非安全数据失效。

3.6地址变换高速缓存

地址变换高速缓存(TLB) 缓存最近使用的翻译。处理器有多个独立的翻译机制。TLB 记录一个条目代表的翻译机制，包括安全状态。虽然 TLB 的结构是由实现定义的，但下图显示了一个示例：

当软件在EL1或EL2发出TLB无效操作(TLBI指令)时，软件以当前安全状态为目标。因此，来自安全状态的TLBI ALLE1会使所有缓存无效S.EL0/1翻译制度的条目。

EL3是一个特例。如前面安全状态中所述，当在EL0/1/2中时，SCR_EL3。NS位控制处理器的安全状态。然而，无论如何，EL3总是处于安全状态SCR_EL3的。NS位。当在EL3时，SCR_EL3。NS让软件控制哪个安全状态动手术。

例如，在EL3执行TBLI ALLE1，使用:

SCR_EL3。NS==0:影响安全EL0/1转换机制

SCR_EL3。NS==1:影响不安全的EL0/1转换机制。

3.7 SMC例外

作为对两种安全状态的支持的一部分，该体系结构包括安全监视器调用（SMC）指令。执行SMC会导致针对EL3的安全监视器调用异常。

SMC通常用于从EL3中的固件或服务请求服务其由可信执行环境托管。SMC最初被带到EL3SMC调度员确定呼叫将由哪个实体处理。如下所示图表：

为了标准化接口，Arm 提供了 SMC 调用约定 (DEN0028) 和电源状态协调接口平台设计文档 (DEN0022)。这些规范列出了如何使用 SMC 请求服务。

Note：在 EL1 执行 SMC 可能会被困在 EL2 中。这对管理程序很有用，因为管理程序可能想要模拟虚拟机看到的固件接口。

SMC 指令在任一安全状态下都不可用在 EL0。当我们查看中断控制器时，我们将在后面的中断中讨论异常。

3.8 安全虚拟化

当 Armv7-A 首次引入虚拟化时，它只是在 Non-secure 状态下添加的。在 Armv8.3 之前，Armv8 也是如此，如下图所示：

如前文在安全状态之间切换中所述，EL3 用于托管固件和安全监视器。安全 EL0/1 托管可信执行环境 (TEE)，它由可信服务和内核组成。不需要多个处于安全状态的虚拟机。这意味着不需要对虚拟化的支持。随着 TrustZone 采用率的提高，一些要求变得明显：

• 一些受信任的服务与特定的受信任内核相关联。对于支持多种服务的设备，它可能需要运行多个受信任的内核。

• 遵循以最小权限运行的原则，需要将一些固件功能移出 EL3。

解决方案是在安全状态下引入对 EL2 的支持，这是 Armv8.4-A 附带的，如下图所示：

S.EL2通常托管安全分区管理器（SPM），而不是完整的虚拟机监控程序。一个SPM允许创建隔离分区，这些分区无法查看其他分区的资源分区。一个系统可以有多个包含可信内核及其可信内核的分区服务。

还可以创建一个分区来存放平台固件，从而无需使用该代码其在EL3处运行。

•启用安全EL2当支持S.EL2时，可以启用或禁用它。控制S.EL2是否启用通过SCR_EL3.EEL2位：

• ◦ 0:S.EL2已禁用，行为与不支持S.EL2的处理器相同

• ◦ 1： S.EL2已启用

•安全状态下的第2阶段翻译

在安全状态下，虚拟机（VM）的阶段1转换可以同时输出安全和非安全地址，由转换表描述符中的NS位控制。这导致两个IPA空间，安全和非安全，每个空间都有自己的第2阶段翻译集如下图所示：

与阶段1表不同，阶段2表条目中没有NS位。对于给定的IPA空间，所有的转换都会产生一个受控制的安全或非安全物理地址通过寄存器位。通常，非安全IPA转换为非安全PA和安全IPA转换为安全PA。

四、系统架构

到目前为止，在本指南中，我们主要关注处理器，但 TrustZone 不仅仅是一组处理器功能。要利用 TrustZone 功能，我们还需要系统其余部分的支持。以下是启用了 TrustZone 的系统的示例：

本节探讨此系统中的关键组件及其在TrustZone中的作用。

4.1 补偿器Completers：外围设备和存储器

在前面的物理地址空间中，我们引入了两个物理地址空间的概念，即Secure和非安全。处理器将正在访问的地址空间导出到内存系统内存系统使用此信息来强制隔离。

在本主题中，我们指的是总线安全和总线非安全。总线安全是指总线访问保护物理地址空间。总线非安全是指总线访问非安全物理地址空间。请记住，在安全状态下，软件可以访问两个物理地址空间。这意味着总线访问的安全性不一定与生成该访问的处理器的安全状态相同。

Note：在 AMBA AXI 和 ACE 中，AxPROT[1] 信号用于指定正在访问的地址空间。与转换表中的 NS 位一样，0 表示安全，1 表示非安全。

理论上，一个系统可以有两个完全独立的内存系统，使用访问的物理地址空间 (AxPROT) 在它们之间进行选择。在实践中，这不太可能。相反，系统像属性一样使用物理地址空间，控制对内存系统中不同设备的访问。

一般而言，我们可以讨论两种类型的存储器和外围设备以及总线补偿器：

• TrustZone 感知

这是一种基于 TrustZone 知识构建并在内部使用访问安全性的设备。

一个例子是通用中断控制器 (GIC)。GIC 由软件在安全和非安全状态下访问。非安全访问只能看到非安全中断。安全访问可以看到所有中断。GIC 实现使用总线事务的安全性来确定要呈现的视图。

• Non-TrustZone 感知

这代表典型系统中的大多数完成者。设备内部不使用总线访问的安全性。

一个例子是一个简单的外围设备，如定时器或片上存储器。每个都是安全的或非安全的，但不是两者兼而有之。

4.2强制隔离

TrustZone有时被称为完全强制保护系统。请求者用信号通知其访问的安全性，并且存储器系统决定是否允许访问。基于内存系统的检查是如何完成的？

在大多数现代系统中，基于存储器系统的检查由互连完成。对于例如，Arm NIC-400允许系统设计师为每个连接的补偿器指定：

•安全

仅向设备传递安全访问。互连为所有非安全设备产生故障而不向设备呈现访问。

•不安全

仅向设备传递非安全访问。互连为所有安全设备产生故障而不向设备呈现访问。

•启动时间可配置

在引导时，系统初始化软件可以将设备编程为安全或非安全。默认值为“安全”。

• TrustZone 感知

互连允许所有的访问通过。连接的设备必须实现隔离。例如：

这种方法适用于 TrustZone 感知设备或完全位于一个地址空间内的设备。对于较大的内存，例如片外 DDR，我们可能希望将内存划分为安全和非安全区域。TrustZone 地址空间控制器 (TZASC)允许我们这样做，如下图所示：

TZASC 类似于内存保护单元 (MPU)，它允许将设备的地址空间分成几个区域。每个区域都指定为安全或非安全。控制TZASC的寄存器只能进行安全访问，只允许安全软件对内存进行分区。TZASC 的一个例子是 Arm TZC-400，它支持多达9 个区域。

Note：片外存储器不如片上存储器安全，因为攻击者更容易读取或修改其内容。片上存储器更安全，但价格昂贵且尺寸有限。与往常一样，我们必须平衡成本、可用性和安全性。再决定哪些资产需要放在片外存储器中以及哪些资产需要保留在芯片上时要小心。

当实现Armv9-A机密领域管理延伸技术（RME）时，内存可以通过粒度保护表在物理地址空间之间动态移动。了解更多信息有关信息，请参阅介绍Arm的Dynamic TrustZone技术博客。

4.3 总线请求者

接下来，我们将查看系统中的总线请求者，如下图所示：

系统中的 A-profile 处理器可识别 TrustZone，并在每次总线访问时发送正确的安全状态。但是，大多数现代 SoC 还包含非处理器总线请求器，例如 GPU 和 DMA 控制器。

与补偿器设备一样，我们可以将系统中的请求者设备大致分为几组：

• TrustZone 感知

一些请求者是 TrustZone 感知的，并且与处理器一样，为每个总线访问提供适当的安全信息。这方面的示例包括根据Arm SMMUv3 规范构建的系统 MMU (SMMU)

• 非TrustZone 感知

并非所有请求者都具备TrustZone 感知能力，尤其是在重用旧IP 时。这样的请求者通常不提供其总线访问的安全信息，或者总是发送相同的值。不支持 TrustZone 的请求者需要访问哪些系统资源？根据对这个问题的回答，我们可以选择以下几种方法之一：

• 设计时间限制

在请求者只需要访问单个物理地址空间的情况下，系统设计人员可以通过以下方式修复它可以访问的地址空间绑定适当的信号。这种解决方案很简单，但不够灵活。

• 可配置的逻辑

提供逻辑以将安全信息添加到请求者的总线访问中。一些互连，如 Arm NIC-400，提供寄存器，安全软件可以在启动时使用这些寄存器来设置附加请求者访问的安全性。这会覆盖请求者自己提供的任何值。这种方法仍然只允许请求者访问单个物理地址空间，但比绑定更灵活。

• SMMU

一个更灵活的选择是SMMU。对于受信任的请求者，SMMU 的行为类似于处于安全状态的 MMU。这包括转换表条目中的 NS 位，控制访问哪个物理地址空间。

4.4 M and R profile Arm 处理器

许多现代设计包括 A-profile, R-profile, 和M-profile处理器的混合。例如，移动设备可能具有运行移动操作系统的 A-profile处理器、用于蜂窝调制解调器的 R-profile 处理器和用于低级系统控制的 M-profile 处理器。下图显示了示例移动设备和您可能会找到的不同处理器：

R profile不像A profile那样支持两种安全状态。这意味着在这些处理器上运行的软件无法控制输出的物理地址空间。通过这种方式，它们的行为与其他不支持TrustZone的总线请求者非常相似。对于没有为 Armv8-M 实现 TrustZone 的 M profile处理器也是如此

通常，这些处理器只需要访问单个物理地址空间。使用我们的示例移动设备，处理器通常包括用于低级系统控制的M profile处理器。这有时被称为系统控制处理器（SCP）。在许多系统中，SCP将是仅安全的设备。这意味着它只需要生成总线安全访问的能力。

4.5 中断

接下来，我们将查看系统中的中断，如下图所示：

通用中断控制器（GIC）支持TrustZone。每个中断源，称为INTID，在GIC规范中被分配给三个组中的一个：

•第0组：安全中断，信号为FIQ

•安全组1：安全中断，信号为IRQ或FIQ

•非安全组1：非安全中断，信号为IRQ或FIQ

这由软件写入GIC[D|R]_IGROUPR和GIC[D |R]_IGRPMODR来控制寄存器，这只能从安全状态完成。分配不是静态的。软件可以在运行时更新分配。

对于配置为安全的INTID，只有总线安全访问才能修改状态和配置对应于安全中断的寄存器字段被读取为非安全总线的0访问。

对于配置为非安全的INTID，安全和非安全总线访问都可以修改状态和配置。

为什么有两个安全组？通常，组 0 用于由EL3 固件处理的中断。这些与低级系统管理功能有关。安全组 1 用于所有其他安全中断源，通常由 S.EL1 或 S.EL2 软件处理。

4.5.1 处理中断

处理器有两个中断异常，IRQ 和 FIQ。当一个中断挂起时， GIC 根据中断组和处理器的当前安全状态使用不同的中断信号：

• 组 0 中断

◦ 始终作为 FIQ 异常发出信号

• 安全组 1

◦ 当前处于安全状态的处理器– IRQ异常

◦当前处于非安全状态的处理器 – FIQ 异常

• 非安全组 1

◦ 当前处于安全状态的处理器 – FIQ 异常

◦ 当前处于非安全状态的处理器 – IRQ 异常

请记住，0 组中断通常用于 EL3 固件。这意味着：

• IRQ 表示当前安全状态的第 1 组中断。

• FIQ 意味着我们需要进入 EL3，要么切换安全状态，要么让固件处理中断。

以下示例显示了如何配置异常路由控制：

上图显示了一种可能的配置。另一种常见的选择是在安全状态下将 FIQ 路由到 EL1。受信任的操作系统将 FIQ 视为向固件或非安全状态让步的请求。这种路由中断的方法使受信任的操作系统有机会在受控庄园中退出。

4.6调试、跟踪和分析

接下来，我们将查看系统中的调试和跟踪组件，如下图所示：

现代 Arm 系统包括支持调试和分析的广泛功能。使用TrustZone，我们必须确保这些功能不会被用来危害系统的安全性。

关于调试功能，请考虑开发新的 SoC。信任不同的开发人员来调试系统的不同部分。芯片公司的工程师需要调试所有部件，包括安全状态代码，并且值得信赖。因此，应

启用所有调试功能。

当芯片交付给 OEM 时，他们仍然需要调试非安全状态软件堆栈。但是，OEM 可能无法调试安全状态代码。

在包含芯片的发货产品中，我们可能希望为应用程序开发人员提供一些调试功能。但我们也想限制调试芯片供应商和OEM 代码的能力。

启用不同调试、跟踪和分析功能的信号有助于我们处理这种情况。这包括单独的信号来控制安全状态和非安全状态下功能的使用。

继续调试示例，这些信号包括：

• DBGEN – TOP级侵入式调试启用，控制两种安全状态下的外部调试

• SPIDEN – 安全侵入式调试启用，控制外部在安全状态下调试的能力

Note：这两个信号是示例。还有其他调试身份验证信号。有关完整列表，请参阅

处理器的技术参考手册。

以下是我们如何使用这些信号的示例：

• 芯片设计人员的早期开发

◦ DGBEN==1 和 SPIDEN==1，启用完整的外部调试

• OEM 进行产品开发

◦ DBGEN==1，启用外部调试安全状态

◦ SPIDEN==0，在安全状态下禁用调试

• 发货产品

◦ DGBEN==0 和 SPIDEN==0，在两种安全状态下禁用外部调试

◦ 仍然可以调试应用程序

因为我们希望在不同阶段的不同信号值开发中，通常使用电子熔断器或认证块连接信号。这是一个例子：

通过在制造过程中熔断保险丝，可以永久禁用外部调试。使用保险丝确实使现场调试更加困难。当保险丝熔断时，它们不能不熔断。认证模块更加灵活。

4.7 其他设备

最后，我们将查看系统中的其他设备，如下图所示：

我们的示例启用 TrustZone 的系统包括一些我们尚未涵盖的设备，但我们需要构建一个实用的系统。

• 一次性可编程存储器(OTP) 或熔断器

这些存储器一旦写入就无法更改。与在每个芯片上包含相同映像的引导 ROM 不同，OTP 可以使用设备唯一值和可能的OEM 唯一值进行编程。

存储在 OTP 中的其中一件事是设备唯一私钥。制造每个芯片时，都会将随机生成的唯一密钥写入 OTP。该设备唯一的私钥用于将数据绑定到芯片。

设备唯一私钥的优点是它可以防止类攻击。如果每个芯片都有相同的密钥，如果一台设备遭到入侵，那么所有类似的设备也将易受攻击。

OTP 还经常用于存储 OEM 公钥的哈希值。与其他存储器相比，OTP 相对昂贵。对于公钥，只存储散列而不存储完整密钥可以节省成本。

• 非易失性计数器

非易失性 (NV) 计数器，可以像更多保险丝一样实现。这是一个只能增加并且永远不能重置的计数器。

NV 计数器用于防止回滚攻击。假设设备上的固件版本 3 中存在已知漏洞。该设备当前运行的是版本4，该漏洞已修复。攻击者可能会尝试将固件降级回版本 3，利用已知漏洞。为了防止这种情况，每次更新固件时都会增加计数。在启动时，会根据 NV计数器检查固件版本。如果不匹配，则设备知道它正在受到攻击。

• Trusted RAM 和 Trusted ROM

这些是片上安全访问专用存储器。

受信任的 ROM 是从中获取第一个引导代码的地方。在芯片上意味着攻击者无法替换它。作为 ROM 意味着被攻击者无法对其进行重新编程。这意味着我们有一个已知的、受信任的执行起点，并将在本指南的软件架构部分进行讨论。

Trusted RAM 通常是几百 KB 的 SRAM。这是在安全状态下运行的软件的工作内存。同样，在芯片上使攻击者难以访问其内容。

4.8可信基础系统架构

可信基础系统架构 (TBSA) 是 Arm 为系统设计人员提供的一套指南。TBSA 就不同用例需要哪些资源提供建议，例如，需要多少位 OTP。

五、软件架构

在处理器和系统架构中的 TrustZone 中，我们探索了硬件中的 TrustZone 支持，包括 Arm 处理器和更广泛的内存系统。本主题着眼于 TrustZone 系统中的软件架构。

TOP级软件架构

下图显示了启用 TrustZone 的系统的典型软件堆栈：

Note：为简单起见，该图不包括管理程序，尽管它们可能存在。

处于安全状态的可信内核托管服务，例如密钥管理或 DRM。在非安全状态下运行的软件需要对这些服务具有受控访问权限。

用户空间应用程序不太可能直接了解 TrustZone。相反，它将使用用户空间库提供的高级 API。该库处理与受信任服务的通信。这类似于图形 API 如何从底层 GPU 提供抽象。

服务库和可信服务之间的通信通常使用内存中的消息队列或邮箱来处理。术语世界共享内存 (WSM) 有时用于描述用于此通信的内存。这些队列必须在两组软件都可以看到的内存中，这意味着非安全内存。这是因为非安全状态只能看到非安全内存。

服务库在邮箱中放置一个或多个请求，然后调用内核空间中的驱动程序。驱动程序负责与可信执行环境 (TEE) 的低级交互，其中可能包括为消息队列分配内存并注册它们与 TEE。请记住，这两个世界在不同的虚拟地址空间中运行，因此它们不能使用虚拟地址进行通信。

驱动程序将调用安全状态，通常使用 SMC。控制将通过 EL3安全监视器传递到 TEE 中的可信内核。内核调用请求的服务，然后可以从队列中读取请求。

5.1 信任消息

在我们刚刚描述的流程中，请求位于位于非安全内存中的队列中。如果：

• 发出初始请求的应用程序是恶意的？

• 其他恶意软件替换了队列中的消息？

TEE 必须假设从非安全状态提供的任何请求或数据可能是恶意的或以其他方式无效。这意味着验证请求或请求者需要在安全状态下完成。这看起来将取决于所提供的受信任服务及其安全要求。没有一个单一的答案。

5.2调度

在 TrustZone 系统中有两个软件栈，一个用于非安全状态，另一个用于安全状态。处理器内核一次只能处于一种状态。谁决定何时允许每个世界运行？

对 EL3 固件的显式调用，例如使用电源状态协调接口 (PSCI) 的电源管理请求，通常是阻塞的。这意味着只有在请求的操作完成时，控制才会返回到非安全状态。但是，这些电话往往很短且不频繁。

TEE 通常在非安全状态 OS 调度程序的控制下运行。一种可能的设计是在操作系统下运行一个守护进程作为 TEE 的占位符。当守护进程由操作系统调度，守护进程通过 SMC 将控制权交给 TEE。然后 TEE 运行，处理未完成的请求，直到下一个调度程序滴答声或中断。然后控制返回到非安全状态 OS。

这可能看起来很奇怪，因为这种方法使不受信任的软件可以控制受信任的软件何时可以执行，这可能会导致拒绝服务攻击。但是，由于TEE 提供服务到非安全状态，阻止它运行只会阻止这些服务可用。例如，攻击者可以阻止用户播放受 DRM 保护的视频。这种攻击不会导致任何信息泄露。这种类型的设计可以确保机密性，但不能确保可用性。

我们可以设计软件堆栈以提供可用性。GIC 允许将安全中断设置为比非安全中断更高的优先级，从而防止非安全状态能够阻止获取安全中断。

5.3 OP-TEE

有许多可信内核，包括商业内核和开源内核。一个例子是 OP-TEE，最初由 ST-Ericsson 开发，但现在由 Linaro 托管的一个开源项目。OP-TEE提供了一个功能齐全的可信执行环境，您可以在 OP-TEE 项目网站上找到详细说明。

OP-TEE的结构如下图所示：

OP-TEE 内核在 S.EL1 中运行，在 S.EL0 中托管受信任的应用程序。受信任的应用程序通过 TEE 内部 API 与 OP-TEE 内核进行通信。TEE 内部 API 是由 GlobalPlatform 组开发的标准 API。GlobalPlatform 致力于开发标准API，许多不同的 TEE 都支持这些 API，而不仅仅是 OP-TEE。

Note：在上图中，受信任的应用程序未显示为 OP-TEE组件。这是因为它们不是核心 OP-TEE 操作系统的一部分。OP-TEE项目确实提供了一些示例可信应用程序供人们试验。

在非安全状态下，内核空间中有一个低级 OP-TEE 驱动程序。这负责处理与 OP-TEE 内核的低级通信。

在非安全用户空间 (EL0) 中，有一个用户空间库实现了另一个GlobalPlatform API。TEE 客户端 API 是应用程序用来访问受信任的应用程序或服务的工具。在大多数情况下，我们不希望应用程序直接使用 TEE 客户端 API。相反，将有另一个特定于服务的库提供更高级别的接口。

OP-TEE 还包括一个称为守护进程-TEE的组件。守护进程-TEE处理由 OP-TEE 支持并需要某种程度的丰富操作系统交互的服务。一个例子是安全存储。

5.3 与非安全虚拟化交互

在到目前为止我们介绍的示例中，我们忽略了可能存在的处于非安全状态的虚拟机管理程序。当存在虚拟机管理程序时，VM 和安全状态之间的大部分通信将通过虚拟机管理程序进行。

例如，在虚拟化环境中，SMC 用于访问固件功能和受信任的服务。固件功能包括诸如电源管理之类的东西，虚拟机管理程序通常不希望虚拟机直接访问这些功能。

虚拟机管理程序可以捕获来自 EL1 的 SMC，这允许虚拟机管理程序检查请求是针对固件服务还是受信任服务。如果请求是针对固件服务的，则虚拟机管理程序可以模拟接口而不是在调用时传递。虚拟机管理程序可以将受信任的服务请求转发到 EL3。您可以在下图中看到这一点：

5.4引导和信任链

引导是任何 TrustZone 系统的关键部分。只有当我们信任在引导流程中在它之前运行的所有软件组件时，才能信任软件组件。这通常被称为信任链。下图显示了一个简化的信任链：

图5-5 系统控制处理器

5.5 引导失败

在受信任的引导系统中，每个组件在加载之前都会验证下一个组件，从而形成信任链。现在让我们看看验证失败时会发生什么。

这种情况没有一个答案。这取决于系统的安全需求以及故障发生在引导处理器的哪个阶段。考虑移动设备中的 SoC 示例。如果验证失败：

• 第二阶段启动映像

SoC 和处理器的初始化需要第二阶段启动映像。如果在此阶段验证失败，我们可能无法确定设备能否安全启动并正常运行。因此，如果在此阶段验证失败，通常是致命的，设备无法开机。

• TEE

TEE 提供服务，例如密钥管理。在没有 TEE 的情况下，该设备仍然可以运行，也许在有限的水平上。因此，我们可以选择不加载 TEE，但仍然允许加载非安全状态软件。

• 非安全状态固件或丰富的操作系统映像

非安全状态软件已经处于较低的信任级别。我们可能会选择允许它启动，但阻止访问通过 TEE 提供的高级功能。例如，启用 TrustZone 的 DRM 可能不适用于不受信任的操作系统映像。

这些只是例子。每个系统都需要根据其安全要求做出自己的决定。

5.6 安全启动设计需求（TBBR）

前面我们介绍了受信任的基本系统架构 (TBSA)，它是系统设计人员的指南。受信任的板引导要求 (TBBR) 是一套类似的软件开发指南。TBBR 提供了有关如何在启用了 TrustZone 的系统中构建可信引导流程的指导。

5.7可信固件

可信固件是用于Armv8-A 设备的 Secure world 软件的开源参考实现。Trusted Firmware 为 SoC 开发人员和 OEM 提供符合相关 Arm 规范（包括 TBBR 和 SMCC）的参考 Trusted 代码库。

下图显示了可信固件的结构：

SMC 调度程序处理传入的 SMC。SMC 调度程序确定哪些 SMC 应在 EL3 处由受信任的固件处理，哪些 SMC 应被转发到受信任的执行环境。

可信固件提供处理 Arm 系统 IP 的代码，例如互连。芯片供应商需要提供处理定制或第三方 IP 的代码。这包括 SoC 特定的电源管理。

六、示例用例

在处理器和系统架构中的 TrustZone 中，我们介绍了硬件中的 TrustZone 功能，并讨论了使用这些功能的典型软件栈。在本主题中，让我们汇总这些知识并查看一些示例用例。

6.1 加密文件系统

智能手机等移动设备包含大量个人数据。如果设备丢失或被盗，用户会关心该数据的机密性。这就是为什么最近的设备支持文件系统加密。TrustZone 可用作保护此数据的解决方案的一部分。

存储在外部闪存中的数据是加密的。在启动时，设备对用户进行身份验证，然后提供解密文件系统的密钥。解密可能由加速器处理，也可能集成到闪存控制器中。

文件系统的密钥也需要保密。如果他们的密钥被泄露，攻击者可以解密文件系统。

认证后的流程如下图所示：

在安全状态下：

• 验证后，加密的文件系统密钥被读入片上安全存储器。使用存储在芯片上的请求者设备唯一密钥对密钥进行解密和检查。

• 文件系统密钥被配置到加密引擎或内存控制器中的仅安全访问寄存器中。

• 对闪存中文件系统的后续总线访问将使用配置的密钥进行加密或解密。

通过在安全状态下执行这些操作，TrustZone 允许我们永远不会将文件系统密钥暴露给非安全状态软件。这意味着Non-secure 中的恶意代码无法提取这些密钥用于以后的攻击。使用我们到目前为止所讨论的内容，思考以下问题：

为什么文件系统密钥存储在芯片外？

与片外闪存相比，片上存储器往往尺寸有限且价格昂贵。将文件系统密钥保持在芯片外可以降低成本。对其进行加密意味着我们可以确保机密性。存在恶意软件可能破坏密钥的风险，这会破坏完整性，但不会暴露数据。

为什么我们在这个例子中使用单独的文件系统密钥，而不是请求者设备唯一的私钥？

理论上，我们可以使用设备唯一密钥。但这意味着我们永远无法更改密钥，因为请求者设备唯一的私钥存储在 OTP 中。这可能是一个问题，如果，例如，我们卖手机。相反，我们生成一个新的随机文件系统密钥。如果您想格式化或重置设备，我们可以删除文件系统密钥并生成一个新的。使用旧密钥加密的任何数据现在都无法恢复。

6.2无线固件更新

第二个示例与更新引导固件有关。我们系统的要求是：

• 通过网络提供新的固件映像。

• 只能安装真实的图像。

• 固件版本无法回滚。

为了实现这些目标，OEM 使用其私钥对图像进行签名。下载设备配备有公钥，可用于验证签名。当固件更新时，非易失性计数器会增加，从而允许检测回滚。

我们的系统如下图所示：

图像的下载是在非安全状态下进行的。图像本身不是秘密，因此我们不保护其机密性。下载的图像被放置在内存中，并向安全状态发出安装它的请求。

安全状态软件负责身份验证。它使用OEM 的公钥来执行此操作，通常存储在片外闪存中。这个密钥不是秘密，所以我们不需要确保机密性。我们确实需要确保密钥的真实性并检测替换密钥的尝试。我们通过在芯片上保存密钥的散列来实现这一点，它可用于在需要时检查密钥。散列需要更少的位并且片上存储器很昂贵。

当加载并检查公钥时，可以检查新的固件映像。我们要确保它是真实的（签名匹配），并且它是比安装的固件版本新的固件。

假设这些检查通过，则安装映像，并且 NV 计数器递增。增加 NV 计数器意味着，如果攻击者尝试安装较旧的固件，设备将检测到该尝试。

在此示例中，TrustZone 允许我们确保用于验证固件映像的密钥受到保护，并且固件映像无法回滚。

七、检查你的知识

以下问题可帮助您测试您的知识。

Arm 架构中的安全状态和物理地址空间是什么？

Arm 架构中的安全状态有安全状态和非安全状态。Arm 架构中的物理地址空间有 Secure 物理地址空间和Non-secure 物理地址空间。

对于每个异常级别，是什么决定了处理器是处于安全状态还是非安全状态？

对于 EL0/1/2，SCR_EL3.NS 位。EL3 始终处于安全状态。

在非安全状态下，软件可以访问安全物理地址空间吗？

不会。在非安全状态下，虚拟地址始终映射到非安全物理地址。

对 SP:0x80000 的访问能否命中包含 NP:0x80000 的缓存行？

没有。SP:0x80000 是 NP:0x80000 是不同的位置，所以没有缓存命中。

受信任的基本系统架构 (TBSA) 和受信任的板引导要求 (TBBR)提供哪些指导？

TBBR 提供引导指导，TBSA 提供系统架构指导。

TrustZone 地址空间控制器 (TZASC) 的用途是什么？

TZASC 允许将内存划分为安全和非安全区域。

八、相关信息

以下是与本指南中的材料相关的一些资源：

• Arm 架构和参考手册：查找与本指南和其他类似主题相关的技术手册和文档。

• Arm 社区：询问开发问题，并查找Arm 专家关于特定主题的文章和博客

• 要了解有关安全虚拟化的更多信息，请参阅我们的白皮书在安全世界中使用虚拟化进行隔离。

• Arm CoreLink 通用中断控制器 v3 和 v4 指南

• 芯片 IP 安全：查找有关可信基础系统架构的更多信息。

• Cortex-A 的TrustZone

• Cortex-M的 TrustZone

• 介绍 Arm 的动态 TrustZone 技术

以下是与本指南中的主题相关的一些资源：

OP-TEE

• OP-TEE 是可信执行环境的一个示例。

• OP-TEE 是一个开源项目。

OP-TEE 实施由全球平台组开发和维护的行业标准 API 。有关这些 API 的信息，请参阅全球平台规范库。• 您可以在免费的 Arm Foundation模型或 Arm Development Studio 提供的 FVP 模型上试验 Trusted Firmware 和 OP-TEE 。

以下是有关构建和运行 Arm 参考平台的更多信息。

SMC 例外

以下规范描述了如何使用 SMC 请求服务：

• SMC 调用约定 (DEN0028)

• 电源状态协调接口规范 (DEN002)

可信板引导要求

• 可信板引导要求：关于如何在

启用了 TrustZone 的系统中构建可信引导流程的指南。受信任的固件

• 受信任的固件：查找一些用于处理 Arm 系统 IP 的示例代码，例如互连。

九、下一步工作

本指南介绍了 TrustZone 安全架构，它提供了两个世界或执行环境之间的隔离。Arm 架构还具有在给定环境中提供强大安全性的功能。要了解更多信息，请阅读我们的安全指南 - 为复杂软件提供保护。

在本指南中，我们提到了虚拟化和 GIC 的主题，但没有完全探索它们。要了解有关这些主题的更多信息，请阅读我们系列中的以下指南：

• Arm CoreLink 通用中断控制器 v3 和 v4 指南

• Armv8-A 虚拟化

• 本指南不涉及 Armv9-A 领域管理扩展 (RME)。有关RME的更多信息，请参阅领域管理扩展指南。