An Exploration of ARM TrustZone Technology

ARM TrustZone技术已有近十年。在x86平台上有关可信平台模块（TPM）的有争议的讨论正在全面展开（TCPA，Palladium）的时候被介绍。相似于TPM芯片意味着使PC“值得信赖”，TrustZone旨在建立对基于ARM的平台的信任。与被设计为具有预定义功能集的固定功能设备的TPM相比，TrustZone通过将CPU用作可自由编程的可信平台模块来表示更灵活的方法。为了做到这一点，除了常规正常模式之外，ARM还引入了一种称为“安全模式”的特殊CPU模式，从而建立了“安全世界”和“正常世界”的概念。两个世界的区别与用户级别和内核级代码之间的正常环保保护完全正交，并且与正常世界中运行的操作系统隐藏。此外，它不限于CPU，而是通过系统总线传播到外围设备和存储器控制器。这样一来，这样一个基于ARM的平台就成了一种分裂的个性。当安全模式处于活动状态时，与在非安全模式下运行的软件相比，CPU上运行的软件与整个系统的视图不同。这样，系统功能，特别是安全功能和加密凭据，可以从正常的世界中隐藏起来。

上图显示了两个世界的概念。正常的世界是活跃的（非安全位被设置），平台上运行的操作系统只能访问物理资源的子集。当世界转换发生时，安全的世界就会生效。在安全世界中运行的系统软件可以访问隐藏在正常世界中的设备。

作为操作系统安全领域的前大学研究人员，ARM TrustZone被认为与我们相关。我们仍然对与意法半导体公司（ROBIN）的联合研究项目有一个很好的回忆，我们可以看到在基于ARM1176的原型平台上使用TrustZone，使用基于L4的安全操作系统共同托管Linux。但是，自2008年结束以来，我们几年来一直没有听说过这项技术。TrustZone看起来像是许多模糊的处理器功能之一，一旦被引入到产品中，没有人会对此感到非常兴奋。那么，在TrustZone的情况下，这实际上是不正确的。在2012年，我们从不同角度接触了有关ARM TrustZone的问题。看来，当时， TrustZone已经成为SoC厂商使用的营销术语，以销售其芯片安全性的信心。“TrustZone”这个词似乎是多云的，它带来了错误的期望和误解。出现了很多问题：TrustZone是否提供安全引导和安全存储的机制？这不是一种虚拟化技术吗？如果是，是不是取代了ARM的虚拟化扩展？它是如何工作的？在开发操作系统时要考虑它很重要吗？TrustZone是否提供安全引导和安全存储的机制？这不是一种虚拟化技术吗？如果是，是不是取代了ARM的虚拟化扩展？它是如何工作的？在开发操作系统时要考虑它很重要吗？TrustZone是否提供安全引导和安全存储的机制？这不是一种虚拟化技术吗？如果是，是不是取代了ARM的虚拟化扩展？它是如何工作的？在开发操作系统时要考虑它很重要吗？

这些问题促使我们潜入到TrustZone的世界。我们花了两年半的时间在几个ARM平台上进行了实验，每个ARM平台对基于TrustZone的安全性有着非常不同的解释。本文总结了我们的发现。

初始点

开始一系列实验时，桌面上的第一个问题是适合开发平台的问题。

当我们开始调查时，我们对基于ARM Cortex-A9的SoC最感兴趣。所有Cortex-A9内核都配备有ARM的安全扩展（通常称为TrustZone功能）。原则上，任何基于Cortex-A9的平台都适合我们。然而，即使市场上有许多低成本的ARM开发板（例如三星，TI，ST-Ericsson，NVIDIA，ZiiLABS），我们发现这些选项都没有提供对TrustZone安全模式的访问。在几乎所有情况下，存储在ROM中的引导代码在启动引导加载程序之前切换到非安全模式，可能会阻止访问SoC的某些部分，这些部分不适用于公共使用。这缩小了FreeScale的潜在基础平台。MX开发板和ARM Versatile Express平台。FreeScale i.MX平台对使用安全模式没有任何限制。但是当我们开始，没有基于Cortex-A9的电路板可用。最新的i.MX53主板采用单核Cortex-A8处理器。ARM Versatile Express Cortex-A9板是ARM的官方参考板，支持ARM TrustZone。正如预期的那样，官方的参考板在您通常的低成本开发板的北部有一个价格标签。这不是更昂贵的数量级。实际上是两个订单！不过，我们很高兴得到我们的其中一个，并可以在官方参考平台上启动我们的实验。MX平台对使用安全模式没有任何限制。但是当我们开始，没有基于Cortex-A9的电路板可用。最新的i.MX53主板采用单核Cortex-A8处理器。ARM Versatile Express Cortex-A9板是ARM的官方参考板，支持ARM TrustZone。正如预期的那样，官方的参考板在您通常的低成本开发板的北部有一个价格标签。这不是更昂贵的数量级。实际上是两个订单！不过，我们很高兴得到我们的其中一个，并可以在官方参考平台上启动我们的实验。MX平台对使用安全模式没有任何限制。但是当我们开始，没有基于Cortex-A9的电路板可用。最新的i.MX53主板采用单核Cortex-A8处理器。ARM Versatile Express Cortex-A9板是ARM的官方参考板，支持ARM TrustZone。正如预期的那样，官方的参考板在您通常的低成本开发板的北部有一个价格标签。这不是更昂贵的数量级。实际上是两个订单！不过，我们很高兴得到我们的其中一个，并可以在官方参考平台上启动我们的实验。ARM Versatile Express Cortex-A9板是ARM的官方参考板，支持ARM TrustZone。正如预期的那样，官方的参考板在您通常的低成本开发板的北部有一个价格标签。这不是更昂贵的数量级。实际上是两个订单！不过，我们很高兴得到我们的其中一个，并可以在官方参考平台上启动我们的实验。ARM Versatile Express Cortex-A9板是ARM的官方参考板，支持ARM TrustZone。正如预期的那样，官方的参考板在您通常的低成本开发板的北部有一个价格标签。这不是更昂贵的数量级。实际上是两个订单！不过，我们很高兴得到我们的其中一个，并可以在官方参考平台上启动我们的实验。

我们进行了两行实验：使用现有的微内核进行原型设计，并创建了一个定制的内核平台。前一系列工作的主要动机是通过低风险途径来实现参考硬件，并了解ARM Cortex-A9的原理使用。通过接受和修改已知的在这个CPU内核上工作的内核平台，我们有一个很好的起点。然而，要彻底了解TrustZone的机制，我们需要解决内核范围内的问题。此外，我们希望完全控制引导过程，特别是解决有关安全启动的问题。而不是修补现有内核并继承其设计选择，

对于这两种工作，我们使用Genode OS Framework（Genode）作为基础。Genode是用于构建专用操作系统的构建工具包。它是一个小型建筑群的集合，其中可以组成复杂的系统。这些构建块不仅包括应用程序，还包括所有经典的OS功能，如内核，设备驱动程序和协议栈。目前，Genode支持8种不同的内核，并为基于x86和ARM的平台提供了超过100个可重复使用的组件。我们认为，其低可信计算基础（TCB）复杂性高灵活性将使其成为指定运行在TrustZone安全端的操作系统的有吸引力的基础。

对于第一线工作，启用多功能Express平台，其中一个内核L4 / Fiasco，Fiasco.OC或Codezero主要是适用的。在这些候选人中，Fiasco.OC为最新的ARM SoC提供了最广泛的支持。因此，我们决定使用Genode与Fiasco.OC的组合作为起点，以便在平台上主要使用Genode。这就要求我们为PL110显示器，PL011 UART，定时器和PS / 2等基本外设实现低级别的驱动程序支持。尽管驱动程序相关工作是使用Fiasco.OC内核进行的，但是对于两种工作方式Fiasco.OC和我们的定制内核，结果都有益于Genode的驱动程序组件独立于底层内核。

在我们的第二线工作中，我们补充了Genode与一个新的基础平台，我们称之为“base-hw”（“hw”代表在裸机上运行的Genode）。与已经支持的内核相反，这个新平台与Genode的核心紧密集成。因此，与使用离散内核相比，我们旨在大大降低基本系统的TCB复杂性。在我们的TrustZone实验的上下文中，定制内核平台最显着的优点是使用Cortex-A9和TrustZone时对内核级问题的深入了解。

我们定制的base-hw内核平台的设计和起源

与传统的L4微内核相比，Genode的核心进程作为用户级根目录在内核上运行，base-hw直接在硬件上执行Genode的内核，而在其下方没有明显的内核。核心和内核融合成一种新型的混合内核/用户程序。在特权模式下只执行几个代码路径，但大多数代码在用户模式下运行。这种设计有几个好处。首先，内核部分变得简单得多。例如，内核部分不需要分配器，因为分配器由核心的用户级部分管理。第二，基于hw侧重长期的硬核级问题，特别是内核资源的管理。对于内核对象的分配，我们可以简单地使用Genode的用户级资源交易概念。最后，最重要的是，将内核与roottask合并可以消除两个程序之间的冗余。传统上，内核和roottask都执行物理资源分配的书保存和内核对象（如地址空间和线程）的存在。在基础上，这些数据结构只存在一次。组合的内核/核心的复杂性显着低于传统自给自足的内核和顶部的独特根任务的复杂性的总和。这样，base-hw有助于使Genode的TCB变得不那么复杂。内核和roottask都执行物理资源分配的书保存和内核对象（如地址空间和线程）的存在。在基础上，这些数据结构只存在一次。组合的内核/核心的复杂性显着低于传统自给自足的内核和顶部的独特根任务的复杂性的总和。这样，base-hw有助于使Genode的TCB变得不那么复杂。内核和roottask都执行物理资源分配的书保存和内核对象（如地址空间和线程）的存在。在基础上，这些数据结构只存在一次。组合的内核/核心的复杂性显着低于传统自给自足的内核和顶部的独特根任务的复杂性的总和。这样，base-hw有助于使Genode的TCB变得不那么复杂。

该图说明了新设计对Genode流程树根目录TCB的影响。在左边，描述了L4系列内核的传统成员。蓝色标记的TCB包括内核，sigma0根内存管理器，roottask（Genode的核心）和Genode的init进程。这些组件累积到大约6万行代码。在右侧，说明了基本hw的混合核心/内核方法。通过将内核与roottask合并，在base-hw之上运行的系统需要信任较少的代码，使其无效。

为了实现基本的内核平台，我们进行了以下步骤。首先，我们设计和实现了将基于Genode的系统引导到包含潜在的许多模块作为单个引导映像的概念。这是第一点，使用自定义平台的股票Fiasco.OC内核是有益的，因为与Fiasco.OC已知的过程相比，我们的引导概念非常简单。

内核入口和出口代码路径已经在Qemu和参考硬件上实现和测试。内核的执行模型可以粗略地表征为单堆栈内核。与传统的L4内核相比，每个用户线程维护一个内核线程，base-hw内核是一个从不在内核中阻塞的状态机。这类似于seL4内核和NOVA微型控制器的工作原理。

下一步是增加对中断处理和抢占式多线程的支持。所以我们实现了PL390中断控制器和Cortex-A9内核定时器的驱动。结合实现的内核入口代码路径和中断控制器，定时器中断可以由Genode的用户级内核处理。Genode的核心组件使用多个执行线程：

初始化平台并产生称为init的第一个用户级进程的主线程，

一个接收和处理页面故障的寻呼机线程，

每个设备一个线程中断，

一个所谓的RPC入口点，用于处理由核心提供的服务的请求，

init进程的父线程通过父接口响应init进程的请求。

因为这些线程的正确运行和调度对于系统的启动是至关重要的，所以下一个逻辑步骤是引入抢占式调度器和核心 - 本地上下文切换。核心本地线程不独立运行，而是通过同步进程间通信相互交互。例如，主线程创建RPC入口点，然后充当一些核心服务的客户端。为了适应这些用例，内核接口补充了用于同步进程间通信（IPC）的系统调用。为了使内核尽可能简单，IPC使用所谓的用户级线程控制块（UTCB）执行。每个线程都有一个对应的内存页面，它始终映射到内核中。本UTCB页面用于承载IPC有效载荷。传递消息的简化过程如下。（实际上，状态空间比较复杂，因为发送方发送消息时接收方可能不处于阻塞状态）

用户级别的发送者将其有效载荷合并到其UTCB中并调用内核，

内核将有效载荷从发送者的UTCB传输到接收器的UTCB，并对接收器进行调度，

接收器从其UTCB检索传入的消息。

因为所有UTCB总是映射到内核中，所以在第二步中不会发生页面错误。这样，内核中的执行流程变得可预测，并始终返回到用户界面。

除IPC之外，线程还可以通过Genode API提供的同步原语进行交互。为了实现API的这些部分，然后通过用于管理线程的执行控制的系统调用来增强内核。

核心实体在参考平台上运行，是产生第一个非核心用户级进程（即init进程）的时候了。这个过程是由多个核心会话组成的：

一个CPU会话与init进程的主线程，

描述进程的地址空间的区域管理器（RM）会话，

表示进程的封装边界的保护域（PD）会话，

包含可用于init进程的物理内存资源的RAM会话。

为了适应这些服务的实现，内核通过系统调用进行了增强，系统调用在用户级别处理保护域和页面错误。

在init进程启动时，它的第一个生命符号是由主线程产生的页面错误，试图获取其第一条指令。内核将此页面故障转换为寻呼机线程的IPC消息。与核心内部IPC相反，这种跨PD-IPC要求内核不仅可以切换线程上下文，还可以切换地址空间。

启动初始化过程（如ELF加载）所需的所有其他功能都可以由Genode OS Framework的通用代码提供。

在自定义内核上执行现实应用场景的最后一步是提供用户级设备驱动程序所需的机制。这些机制是通过内核IO_MEM和IRQ服务提供的内存映射I / O访问和IRQ传递。为了实现这些服务，内核必须补充用于分配和接收IRQ的系统调用。

通过这些功能，当使用Fiasco.OC内核（即用户级定时器，帧缓冲区和PS / 2输入设备的驱动程序）时，路径被清除以执行我们已经启用的用户级设备驱动程序。因此，我们可以在我们的定制内核上运行基本的图形交互式演示场景。

对于需要异步通信的更复杂的工作负载，我们随后改进了内核机制。例如，我们为Genode的信令API添加了内核级支持，从而在我们的定制内核平台上完全覆盖了Genode API。

管理程序管理非安全的世界

本节介绍了我们在创建一个能够在一个非安全虚拟机（VM）之间进行计划的TrustZone感知管理程序以及在安全模式下运行非特权的多个任务之间的体验。基于我们的定制基础内核平台，它描述了将内核转换为TrustZone感知虚拟机管理程序所采取的连续步骤，以及构建以顶级用户级组件运行的虚拟机监视器（VMM）的内核。

世界在不安全的世界和安全的世界之间切换

我们开始调查TrustZone，将所谓的监视器模式引入Genode / ARM内核。监视器模式是实现安全扩展的ARM CPU中的执行模式附加（SE相当于TrustZone）。它是一种执行模式（如系统，用户或管理员模式），当某些异常发生时，CPU会切换到该模式。对于大多数异常，可以配置CPU是否在监视模式下引发异常，或者在非安全或安全世界的相应异常模式下引发异常。所谓的安全配置寄存器（SCR）使得管理程序可以配置当非安全环境处于活动状态时，快速中断或正常中断或外部数据中止时CPU是否陷阱。

除了中断触发模式开关之外，非安全的世界还能够通过smc指令通过软件产生的异常来明确地进入监视模式。因此，第一步是初始化引发监视模式异常时使用的对应异常向量。

因此，我们的考虑是，进入监控模式的所有例外都应该由非安全的世界触发，而不是安全的世界。假设这个假设，我们设计了异常向量，它总是将当前的CPU状态存储为一个非安全的世界状态。无论异常类型如何，都会保存CPU状态。除CPU状态外，异常类型存储在同一区域。在切换到监视器模式时，内核从已知的存储区重新加载以前存储的安全内核上下文。给定这种方法，在安全环境中运行的软件堆栈不能执行smc指令。这大大简化了汇编器世界切换程序。 在安全世界中执行的组件子集不可信的应用场景中，主要可能扩展世界切换例程来检查引起故障的世界。通常，监视模式异常向量与内核/用户模式交换机正交。相比之下，世界开关必须保存/恢复更多的注册银行。为了从安全的世界切换到非安全的世界，还要执行对称的操作，只有这一次，世界切换不是由异常触发，而是通过新引入的具有指向VM的CPU状态的指针的系统调用。内核通过将提供的状态推送到非安全的世界来响应该系统调用。主要可能扩展世界转换程序来检查引起故障的世界。通常，监视模式异常向量与内核/用户模式交换机正交。相比之下，世界开关必须保存/恢复更多的注册银行。为了从安全的世界切换到非安全的世界，还要执行对称的操作，只有这一次，世界切换不是由异常触发，而是通过新引入的具有指向VM的CPU状态的指针的系统调用。内核通过将提供的状态推送到非安全的世界来响应该系统调用。主要可能扩展世界转换程序来检查引起故障的世界。通常，监视模式异常向量与内核/用户模式交换机正交。相比之下，世界开关必须保存/恢复更多的注册银行。为了从安全的世界切换到非安全的世界，还要执行对称的操作，只有这一次，世界切换不是由异常触发，而是通过新引入的具有指向VM的CPU状态的指针的系统调用。内核通过将提供的状态推送到非安全的世界来响应该系统调用。相比之下，世界开关必须保存/恢复更多的注册银行。为了从安全的世界切换到非安全的世界，还要执行对称的操作，只有这一次，世界切换不是由异常触发，而是通过新引入的具有指向VM的CPU状态的指针的系统调用。内核通过将提供的状态推送到非安全的世界来响应该系统调用。相比之下，世界开关必须保存/恢复更多的注册银行。为了从安全的世界切换到非安全的世界，还要执行对称的操作，只有这一次，世界切换不是由异常触发，而是通过新引入的具有指向VM的CPU状态的指针的系统调用。内核通过将提供的状态推送到非安全的世界来响应该系统调用。

用户级虚拟机监视器（VMM）

为了能够使用新引入的切换到非安全环境的系统调用，我们在Genode的核心中引入了一个新的VM会话接口作为服务。该接口使客户机（VMM）能够影响虚拟机的整个CPU状态，启动世界切换到非安全的世界，并在异常触发的返回之后获取虚拟机的状态。此外，新的接口使客户端能够获得物理RAM的一部分作为I / O存储器，以便它可以将其准备为虚拟机的物理RAM。将这个物理RAM部分移动到内核的I / O内存分配器中，可以使VMM获取适当的RAM部分，以将VM的ELF映像加载到其物理重定位地址。

上图显示了用户级VMM（TZ VMM）和Genode核心/内核之间的关系。TZ VMM通过调用VM会话接口的运行功能启动切换到正常的世界。正常的世界被基准hw内核调度为（低优先级）的线程。

鉴于内核中的世界交换例程和核心的VM会话接口，所有先决条件都已经到位，以构建VMM的第一个简单版本。此版本仅获取RAM的一部分，使用ROM模块（VM的映像加载），并将ELF二进制文件加载到物理RAM。在ELF加载期间，它识别正确的入口点，并相应地设置VM的CPU状态的程序计数器。最后，VMM进入无限循环，在那里它执行虚拟机，并且在每个异常返回后，将虚拟机的CPU状态转储到调试控制台。

简单的测试内核为非安全的世界

为了测试新实现的世界交换例程，我们创建了一个简单的测试内核。它几乎完全由汇编代码构建，它执行以下步骤：

设置用于数据中止，预取中止，中断，快速中断，主管调用的异常向量，

初始化中断控制器以接收UART0中断，

初始化UART0可以打印简单的消息，并检测中断接收（RX），

切换到用户模式并空闲，

每当发生中断时，都会打印一些短信。

TrustZone平台控制器（TZPC）和地址空间控制器（TZASC）

在成功测试VMM设置和世界交换例程之后，现在是调查TrustZone机制的时候了，这实际上保护了安全的世界免受非安全的世界的影响。CPU核心之外存在一组不同的IP核，这有助于限制非安全软件堆栈。关于Versatile Express平台，具体如下：

TrustZone保护控制器（TZPC）

TrustZone地址空间控制器（TZASC）

Cortex A9 MPCore内部中断控制器

第一个也是最简单的部分似乎是应该为安全世界保留的物理内存区域的配置，但对于非安全的世界，即安全软件堆栈所在的RAM，不可见。总线和内存层次结构在现代嵌入式架构中，像Versatile Express主板/子板集团一样，非常复杂。它由不同的总线系统（ABP，AXI），内存控制器（SMC，DMC）和高速缓存组成。这个丛林中的大多数控制器和设备不是TrustZone意识到自己，而是受到TZPC或TZASC的保护。鉴于技术参考手册中公布的信息稀缺，很难确定哪些组件可以被保护，以及TZPC / TZASC如何与之相关。

由于实验，我们能够扣除以下见解。平台上的TZASC控制器用于保护通过静态内存控制器（SMC）可寻址的物理地址范围。原则上，也可以通过TZASC来确保另一个内存控制器，但在平台上，它只能用于SMC。这些物理地址区域对应于外围设备，一些SRAM和闪存的I / O资源。这些组件中的大多数都放置在主板上。另一方面，DDR RAM不受SMC的影响，而是位于动态内存控制器（DMC）之后，不受任何TZASC的保护。在TZASC的帮助下，可以将多个区域定义为安全或不安全。然而，

TZPC用于保护片上外设（例如，TZPC和TZASC本身）以及总线访问外部子系统。因此，可以配置是否允许对对应的片上设备的访问。例如，TZPC中有一位被保留以启用或禁用来自非安全世界的DMC访问。TZPC不允许对单个设备（例如DMC）进行更细粒度的限制。

鉴于这些发现，Versatile Express平台显然不允许将DDR RAM分区为安全和非安全的地址范围。人们只能决定把它分配给两个世界。另一方面，在TZASC控制下的SRAM和闪存可以配置得更细粒度。此外，当在非安全的世界中运行未经修改的Linux软件堆栈时，我们需要将整个DDR RAM分配给非安全的世界。幸运的是，该平台拥有32个SRAM的SRAM，我们可以保护安全的世界独家使用。

中断

在上一节中，我们通过将外设的内存映射I / O（MMIO）资源分配给两个世界之一来确定如何将参考平台的物理资源分为两个世界。然而，进入MMIO只是实际使用这些外设的一半。我们还需要一种将相应的设备中断路由到相应的世界。

不幸的是，无法直接配置设备中断到安全或非安全的世界。相反，仅仅可以区分正常中断（IRQ）和快速中断（FIQ）的处理。ARM架构定义了这两种类型，它们在以下方面有所不同：

每种类型都有一个唯一的异常向量，因此FIQ使用与IRQ不同的代码路径进入内核。

在发生IRQ时，与FIQ相比，CPU自动保存更全面的寄存器状态。

最显着的特征是FIQ可以抢占除FIQ处理程序之外的任何异常处理程序。所以异常可以嵌套。

对于器件中断，可以定义是否在PIC配置中使用IRQ或FIQ异常条目。这种机制间接地通过配置PIC为非安全世界的安全和IRQ使用FIQ来分隔两个世界之间的中断。使用安全配置寄存器，可以从非安全的世界撤销使用FIQ，并且在非安全模式处于活动状态时对每个FIQ强制使用陷阱进入监视器。为了实现这个想法，我们修改了自定义内核来处理FIQ而不是IRQ，这是因为可能的异常嵌套而复杂得多。我们通过检查FIQ发生时活动的始发CPU模式来解决嵌套异常的问题。如果CPU已经处于内核模式，我们可以得出结论，异常是指嵌套异常。在这种情况下，我们忽略FIQ，并回退以恢复之前的异常。

综上所述，FIQ专门由安全世界的设备驱动程序使用，而IRQ仅由非安全的世界专门使用（如Linux内核所预期的）。因为对于每个设备，我们可以定义它的中断是作为FIQ还是IRQ发送，因此我们可以将两个设备中断分配给两个世界。

在非安全的世界中引导Linux

在安全和非安全的世界之间进行主要的分离，我们现在可以用Linux内核替换我们简单的定制非安全内核。这项工作包括以下步骤：

加载内核 内核必须补充有额外的引导时间信息称为ATAG。ATAG的数据结构包含RAM的位置，RAM磁盘的地址以及内核命令行。

除了内核之外，还必须将RAM磁盘加载到非安全世界的内存中。该RAM磁盘包含初始引导映像。

为了测试加载过程，我们启动了Linux，授予对外设的所有访问权限，并观察到内核的成功引导。在这一点上，我们禁用了对所有外设的访问，并进入引导内核的迭代过程，查看其由于缺少许可而挂起的位置，然后执行以下决定之一：对于我们认为对安全性不重要的设备世界，我们将允许直接的设备访问。对于必须为安全世界保留的设备，我们稍微更改了Linux内核代码，以发出一个超级调用，而不是直接访问设备资源。当非安全操作系统使用smc指令进行超调时，CPU进入监控模式，并将控制权传给管理程序。 虚拟机管理程序反映了对用户级VMM的高调，该VMM能够响应各个超级调用。那些超调是：

SP810_ENABLE启用定时器。CPU_ID：请求CPU ID，这是参考平台的硬编码值0x0c000191。SYS_COUNTER返回Sys_24MHz系统寄存器的值。MISC_FLAGS返回Sys_misc系统寄存器的值。SYS_CTRL执行系统配置控制OSC1，DVI_SRC和DVI_MODE之一。MCI_STATUS返回Sys_mci系统寄存器的值。

我们希望对这些寄存器访问采用陷阱和执行仿真方案。然而，如以下部分所述，该技术对于TrustZone提供的机制是不可行的。

设备仿真

我们将设备仿真视为引入超调的较少侵入性替代方案。与超调方法相比，设备仿真不需要我们更改Linux内核。

仿真设备访问的基本思想是，一旦非安全操作系统访问允许的物理地址范围之外的地址，虚拟机管理程序就会将控制权传递给VMM。然后，VMM可以检查有问题的地址和引发访问冲突的非安全操作系统的程序计数器。给定程序计数器值，VMM可以读取和解码故障指令并以软件模拟。由于ARM是RISC架构，因此指令解码相当简单。该指令只能是加载或存储指令。没有其他指令会引起访问故障。对于读取操作，VMM将通过更改VM状态结构的相应条目来提供操作的结果。

也就是说，我们发现陷阱和执行仿真模型无法通过TrustZone保护机制来实现。根据具体平台，当故障发生时，CPU不会立即进入管理程序，而是尝试执行总线事务。此事务将触发外部数据中止。该中止与设备中断相似。它主要引发异常（因此可以检测到违规），但并不总是立即执行。因此，无法唯一地重建在虚拟机管理程序中无效访问和接收外部中止异常之间发生的情况。管理程序也不能将非安全的世界恢复到有用的状态。

上图显示了正常世界OS执行非法设备访问时的控制流程。Genode系统从安全的世界开始。用户级TZ VMM组件引导丰富的操作系统，最后通过内核的运行功能控制到正常的世界，这反过来又启动了一个世界切换到正常的世界。如果富OS操作系统访问未分配给正常世界的设备，则会发生外部数据中止，并将控制权传回给安全的世界。虚拟设备型号可能会尝试捕获并执行故障指令。

我们发现，通过为故障代码添加内存障碍，可以减少报告访问冲突的延迟。然而，由于这是因为改变了Linux内核，所以这将打破使用设备仿真而不是引入超调的初始激励。

将原始代码更改为使用超级调用的一般模式如下（ctr指关键设备寄存器）：

 +#ifdef RUNS_IN_SECURE_WORLD   if (ctr)     return readl(ctr); +#else + if (ctr) { +   static u32 ret; +   asm volatile("mov r1, #3       \n" +          "dsb              \n" +          "dmb              \n" +          "smc              \n" +          "mov %[value], r0 \n" : [value] "=r" (ret) :: "r0", "r1"); +   return ret; + } +#endif

我们用上面的代码段将原来的调用替换为访问函数readl（ctr）。

Linux内核随时可用的配置以及对内核源代码的必要修改可在此处获得：

适应Linux内核

                             https://github.com/skalk/linux/commit/284073c4f6c0e6a77c02ae9d296da9c46f6f5104.patch

我们试图让内核补丁尽可能的小。该补丁包括向内核添加只有73行代码（6个超级调用）。通过这些修改，我们可以在非安全的世界中完全启动Linux。

TrustZone以彩色显示

我们的ARM TrustZone实验的目标是将移动平板设备上的TPM类功能的典型范围超越这一技术。我们的目标是在正常世界中运行一个基本上未经修改的Android操作系统，在安全的世界中执行一个完整的基于Genode的操作系统。安全操作系统不仅仅是坐在后台，而且配有一个图形用户界面，通过触摸屏响应用户的输入。在任何时候，用户都可以使用按钮在两个世界之间切换。

我们确定了飞思卡尔i.MX53 SABRE平板电脑作为本实验的合适平台。它是少数ARM开发平台之一，允许开发人员访问TrustZone的安全世界，并具有平板电脑外形。当我们在ARM Versatile Express平台上进行最初的TrustZone相关研究时，我们还有兴趣了解更多关于两个不同SoC供应商的TrustZone实现的差异。

实际工作包括以下步骤：

将Genode适应于i.MX53平台，在i.MX53上启用TrustZone，执行一个TrustZone监视器来处理i.MX53的细节，目的是在除Genode之外的正常世界中启动Linux，在Genode上显示驱动程序作为用户级设备驱动程序运行触摸屏驱动程序作为Genode上的用户级设备驱动程序运行将Genode的显示和用户输入驱动程序与Android软件堆栈进行接口。使用硬件重叠式复合Android和Genode之间的显示。在下文中，将简要介绍每一个主题。

i.MX53 SABRE平板电脑上的Genode

我们在基于Cortex-A9 CPU的ARM Versatile Express平台上进行了第一次TrustZone实验。借助飞思卡尔i.MX53，我们将挑战转移到完全不同的平台上。我们考虑了基于i.MX53的平台的两种变体。所谓的快速启动板（QSB）是一种低成本开发板，而SABER平板电脑参考平台则是平板电脑的尺寸。Genode适应新平台的原则需要我们向内核增加对Cortex-A8 CPU的支持，并为i.MX特定的中断控制器，UART，GPIO和EPIT定时器添加设备驱动程序。通过这些调整，可以在平台上执行简单的Genode场景。

TrustZone on i.MX53

由于i.MX53 SoC基于Cortex-A8 CPU而不是Versatile Express平台上使用的Cortex-A9，我们预计对TrustZone世界切换代码进行微小的更改。

一个特定的i.MX特定的区别是中断的路由。因为i.MX使用自定义中断控制器，所以将中断分配给安全或正常的世界与ARM Versatile Express平台的工作方式略有不同。此外，i.MX53还附带了一个名为Central Security Unit（CSU）的定制TrustZone保护控制器。与Versatile Express平台上使用的TrustZone保护控制器类似，CSU允许使用相应的配置位将设备组分配给安全或正常的世界。CSU区分64个设备组。将各个设备分配给可微分组由SoC供应商决定。与ARM Cortex A9参考板中的ARM TZ保护控制器相比，CSU的一个值得注意的优势是如何处理访问冲突。如设备仿真中所述，ARM TZ保护控制器通过异步外部中止异常来响应无效访问，类似于器件中断。在执行违规指令时，TZ保护控制器检测到违规，但CPU将继续执行进一步的指令，直到被标记的违规最终到达CPU，触发外部中止异常。该方案有效排除了模拟设备访问的任何尝试。相比之下，i.MX CSU通过同步控制异常处理程序来响应访问冲突。 所以当发生这种异常时，可以用软件确定和仿真违规指令。然而，即使使用CSU的设备仿真主要是可能的，我们还没有进一步调查这个机会。

i.MX53与Versatile Express平台相比的第二个显着特征就是所谓的多主器件多存储器接口（M4IF），它是DDR内存控制器的一部分。在Versatile Express平台上，我们使用32个MiB SRAM作为Genode，并将DDR内存分配给正常的世界。在i.MX53上，该方案不起作用，除了DDR RAM之外，还没有大量的内存可用。这排除了使用CSU的内存分区。然而，M4IF可以对DDR RAM资源进行掩蔽，从而可以保留特定的范围，以便安全的世界进行独占访问。我们成功地使用了M4IF来在安全的世界和正常的世界之间分配DDR RAM。

TrustZone监视器

i.MX53的用户级TrustZone监视器（我们称之为VMM，因为它类似于虚拟机监视器）必须从头开始。几乎没有可以重复使用Versatile Express平台的代码。对我们来说，这种经验是对TrustZone技术的宝贵洞察。即使统一两个世界之间的信任分隔机制，SoC供应商也可以实施各自的安全解释。即，将设备分配给保护控制器的位，用于违规的信令机制，由设备处理NS位或附加的TZ相关总线组件不是标准化的。因此，仅仅声称产品使用TrustZone不会自动暗示存在任何有意义的安全机制。如果SoC供应商没有想到产品的用例，这是不幸的。例如，在大多数应用场景中，TrustZone被用作正常世界显式调用的类似TPM的组件。它本身并不活跃。然而，在我们的例子中，安全世界执行一个完整的操作系统，包括抢先的调度程序。因此，在我们的情况下，访问时钟和电源管理变得至关重要。不幸的是，时钟和电源管理模块不支持来自正常世界的选定时钟和稳压器的保护。整个模块可以分配给正常的世界或安全的世界。在前一种情况下，安全的活力将取决于正常的世界。后一种情况将需要实施广泛的设备仿真代码以在正常世界中使用未修改的OS内核。

对于我们的原型，我们将平台分为轻松可行（例如，对于DDR内存，中断），但是我们没有尝试实现设备仿真器。在时钟和电源管理模块的情况下，我们决定授予正常世界上的设备访问权限，但在Linux内核中禁用代码路径会干扰安全世界的活力。我们认为这种做法适合示威者。为了建立一个真正的产品，这个决定将归结为一个平静的判断。

由i.MX53特定的VMM实现的超级呼叫与几个不能直接传递给正常世界的平台功能的访问相关，特别是虚拟帧缓冲区和虚拟触摸屏。

附加设备驱动程序

除了上面列出的低级驱动程序之外，演示场景还要求我们实现一些外围设备驱动程序，特别是LCD显示器的帧缓冲驱动程序，触摸屏驱动程序和用于响应SABER平板电脑

创建驱动程序的任务，特别是帧缓冲区驱动程序，其结果比预期更复杂。即使我们有可用的图像处理单元（IPU）的文档，该设备非常复杂。IPU的规格约为1000页。为了专注于与我们相关的部件，我们转而分析与供应商内核一起提供的驱动程序的寄存器跟踪。不幸的是，我们发现驱动程序代码非常不稳定，容易出现竞争条件。例如，由驱动程序执行的寄存器访问稍微减慢的添加的检测代码将导致有缺陷的驱动程序。我们最终能够将问题指向一些关键的登记册访问模式，但这是一个长期以来的努力。

与framebuffer驱动程序相比，启用触摸屏设备是一个顺利的体验，没有什么大惊喜。使用两个framebuffer驱动程序和触摸屏驱动程序，我们可以在SABER平板电脑上成功运行Genode的Nitpicker GUI服务器。然而，在初始实现中，Nitpicker需要通过软件blitting将其GUI客户端的像素复制到物理帧缓冲区。即使我们为ARM提供了组装优化的blitting程序，我们预计，与没有任何间接的Android的本地执行相比，运行Android作为Nitpicker客户端的显着的性能开销。因此，我们调查了硬件覆盖的使用情况。

与大多数嵌入式图形设备类似，i.MX53图像处理单元（IPU）具有从许多所谓的硬件叠加层构成最终图像的能力。每个叠加层由通过DMA获取的像素流馈送。物理像素颜色是每像素评估的合成函数的结果。该功能可以优先于一个特定的覆盖，其效果是相应的覆盖层始终显示在所有其他叠加层之上。或者，可以使用颜色键控来确定在给定屏幕位置处哪个覆盖是可见的。IPU甚至可以混合不同叠加层的颜色（Alpha混合）。因为IPU使用DMA直接从存储器中获取像素，并且像素合成功能在硬件中执行，

由于我们希望在正常世界中以几乎原生的性能运行Android，因此我们发现使用硬件覆盖是强制性的。不幸的是，i.MX53 IPU的硬件覆盖功能的探索证明是非常复杂的，所以我们不得不在快速启动板上投入大量的开发时间来启用此功能，只是为了发现该功能的行为不同在SABRE平板电脑上。由于SABER平板电脑平台的使用者似乎几乎没有任何社区，因此我们无法利用任何公共社区的知识。我们最终发现，看似松散相关的寄存器访问的顺序是驱动程序达到功能状态的转折点。

通过我们的定制IPU驱动程序与硬件覆盖支持到位，似乎铺平了安全地复合在正常世界中运行的（不信任的）Android和Genode的Nitpicker GUI服务器之间的运行在安全的世界中的显示。因为可以在i.MX53 CSU中单独配置来自两个世界的IPU和GPU的访问，所以我们可以将IPU专门分配给安全的世界，同时将GPU发送到正常的世界。这样，Android可以利用硬件加速的图形，而安全的世界保持对显示器的控制。

不过不幸的是，i.MX53 SoC的TrustZone实现有一个限制，使得IPU和GPU之间的隔离无效。从SRLabs的安全研究人员的调查中，我们了解到，即使CSU可以配置为限制从世界各地到个别设备的访问，也没有办法单独限制从每个设备到安全和正常世界 设备IPU和GPU都需要直接内存访问（DMA）才能运行。IPU使用DMA从帧缓冲区中提取像素。GPU使用DMA来访问GPU缓冲区对象（包含纹理，着色器，顶点数组）和渲染操作的目标表面。在i.MX53上， 在将GPU的DMA操作限制到正常世界的内存的情况下，不可能将IPU的DMA访问配置到安全世界的存储器。实际上，设备IPU和GPU两者共享相同的DMA通道ID。因此，我们必须授予从两个设备的DMA访问到两个世界的记忆。这样，正常的世界实际上能够通过GPU危及使用DMA的安全世界。感谢SRLabs的宝贵见解！要解决这个安全漏洞，SoC将需要分离两个设备的DMA策略，或者安全的将需要虚拟化GPU。我们必须授予从两个设备的DMA访问到两个世界的记忆。这样，正常的世界实际上能够通过GPU危及使用DMA的安全世界。感谢SRLabs的宝贵见解！要解决这个安全漏洞，SoC将需要分离两个设备的DMA策略，或者安全的将需要虚拟化GPU。我们必须授予从两个设备的DMA访问到两个世界的记忆。这样，正常的世界实际上能够通过GPU危及使用DMA的安全世界。感谢SRLabs的宝贵见解！要解决这个安全漏洞，SoC将需要分离两个设备的DMA策略，或者安全的将需要虚拟化GPU。

演示场景

i.MX53上TrustZone演示的架构概述

图6概述了演示场景的关键组件。虚线表示信息流。实线表示控制关系。

在引导时，Genode的核心设置了CSU配置，从而定义了正常世界访问外设的权限。CSU被配置为使得诸如IPU和触摸屏控制器之类的安全关键外围设备仅为安全环境保留。并非所有相关设备都被描绘（例如，图片中省略了定时器和GPIO控制器）。平台初始化后，核心产生Genode进程树，其中包含多个用户级设备驱动程序以及用户级TZ VMM。VMM负责管理正常的世界。特别地，它加载正常世界OS的图像，并使用核心提供的服务将切换触发到正常世界。每一次，正常的世界将控制传递给安全的世界或尝试执行无效操作，核心反映了所产生的世界切换到VMM。因此，VMM可以处理超级调用或相应调用一个仿真函数，并显式地产生回到正常世界的控制。

对于演示场景，VMM向正常世界提供虚拟帧缓冲区和虚拟触摸屏设备。为了使VMM的复杂性保持在低水平，正常世界与这些虚拟设备的交互作用被实现为超级调用（而不是复杂的i.MX硬件设备的忠实仿真）。CSU被配置为使得Android OS能够直接访问图形处理单元（GPU）。然而，GPU将所有渲染操作定位到虚拟帧缓冲器，而不是由IPU使用的物理帧缓冲区。这样，VMM可以故意地将GPU输出引导到专用缓冲器，该专用缓冲器使用硬件覆盖层组成物理屏幕。因为帧缓冲区驱动是控制IPU的唯一软件组件，显示器仍然在安全世界的唯一控制之下，但是存在正常世界的像素到显示器的直接数据路径。因此，Android在演示场景中的图形性能与在同一平台上本机执行的Android的性能相当。

用户输入始终由安全世界通过触摸屏驱动程序和Nitpicker GUI服务器接收。因此，用户输入事件的路由策略始终处于安全世界的控制之下。只有当TZ VMM具有当前输入焦点时，nitpicker会将输入事件路由到VMM，这反过来将这些事件转换为Android使用的虚拟触摸屏的输入事件。

Genode下面的分支机构提供了演示场景。

https://github.com/skalk/genode/tree/i.MX53_tablet_demo

Genode作为i.MX53 SABRE平板电脑上的安全操作系统。

有关复制的详细说明由OS / src / server / vmm / imx53 /目录下的README 文件提供 。

常见问题，回答

在本节中，我们尝试回答我们多次提出的常见问题。请注意，我们绝对不是所有领域的专家。所以如果你发现错误，请报告他们，最好在我们的邮件列表上。

TrustZone的功能是什么？

TrustZone技术可以从两个角度来看待，如虚拟化解决方案和实现类似于可信平台模块（TPM）的功能的机制。当被视为虚拟化解决方案时，TrustZone严重缺乏。

虚拟机的数量限制在两个，一个在安全的世界中运行，一个在非安全的世界中运行。没有办法保护共享非安全世界的多个操作系统。

不支持通过陷阱执行模型虚拟化MMIO资源。如设备仿真部分所述，可以检测到非安全操作系统的访问冲突，但未被仿真。因此，为了两个世界复用单个设备是不可能以透明的方式。

为了保证两个世界只能访问不同的设备资源，必须修改非安全操作系统的某些设备驱动程序。使用TrustZone不是透明的。尽管这些修改是次要的，但这种限制有效地防止了只能作为二进制文件使用的操作系统的重用。

无法虚拟化非安全操作系统所使用的物理内存。客体物理内存总是对应于主机物理内存。

尽管有这些限制，我们确定了TrustZone与其他虚拟化技术（如VT-x和最近的ARM虚拟化扩展）相比的单一优势，这是将设备中断直接分配给非安全的世界，而不涉及VMM作为间接的。

我们最终得出的结论是，将TrustZone视为虚拟化机制是不健全的。当看到TrustZone作为TPM的替代品时，这种技术背后的动机变得更加清晰。与固定功能的TPM相比，TrustZone是一个非常多用途的机制。当前活动的世界由互连处的所谓非安全位（NS位）表示。NS位被路由到与附加地址线类似的外设。这使得外设能够通过实施NS模式的限制性策略来响应此条件。因此，在TrustZone的安全世界中实现的安全功能可以利用这样的外围设备。与TPM相反，TrustZone的安全世界的安全功能可以使用强大的通用CPU架构自由编程。Genode OS框架（作为一个复杂的基于组件的操作系统的海报孩子）到安全的世界的端口在这方面是说明性的。相比之下，在TPM内部运行的Genode自然就不成问题了。

TrustZone区分的局限性是什么？

只有两个“世界”。

可以限制非安全侧对物理地址空间的访问，但物理地址不被虚拟化。

访问限制的粒度取决于SoC。例如，Versatile Express平台不提供将DDR RAM分为安全和非安全区域的方法。相比之下，飞思卡尔i.MX SoC提供了这种主要的能力。

使用TrustZone对于非安全方面来说并不完全透明，因为不可访问的物理资源在物理地址空间中显示为空洞。此外，不能透明地模拟对中央设备（如系统控制寄存器）的访问。在非安全世界中运行的操作系统必须稍加修改。

如何托管两个不同的隔间/区域（一个受信任，一个不受信任）？

一般方法包括以下步骤：

系统以安全模式启动并启动管理程序。管理程序设置非安全的世界（即，通过配置TZPC，TZASC和PIC）。管理程序加载要在非安全环境中执行的OS映像。虚拟机管理程序在非安全操作系统的入口处进入非安全的世界。非安全的操作系统会为非安全的世界隐藏的功能发出超调。这些超级调用由管理程序处理。在我们的特定实验中，管理程序由Genode OS的一个实例表示，它将超级调用的处理与使用微内核技术的低级模式切换分开。该过程的各个步骤在管理非安全世界的虚拟机管理程序部分中有更详细的介绍 。

在安全的世界里运行诸如Android的商品操作系统是否有意义？

遵循Section的理由TrustZone的功能是什么？，TrustZone的使用仅对实现安全功能才有意义。因此，实施的复杂性至关重要。传统上，在安全世界中执行的代码具有类库功能。在安全的世界中运行完整的操作系统，如Genode，可以增加更多复杂性的成本。在安全的世界上运行一个单一的操作系统将增加多个数量级的复杂性。

在诸如Versatile Express平台的平台上，当运行非安全操作系统时，只有少部分内存可以保存到安全的世界。即，特定的平台托管了32 MiB的SRAM。这种限制自然地排除了复杂的操作系统，如Android。

TrustZone如何与ARM的虚拟化扩展进行比较？

Cortex-A15引入的虚拟化扩展与TrustZone正交。Cortex-A9和Cortex-A15的TrustZone实现没有重大变化。

虚拟化扩展将虚拟机监视器的实现设计为非安全性世界的一部分。这些扩展在安全世界中是不可用的（这与在安全环境中实现类似TPM的功能的想法一致）。

那么Cortex-A15在A9架构上有什么安全改进呢？

Cortex-A15引入的虚拟化扩展提供了一种额外的仪器，用于通过非安全侧的“Hyp”（虚拟机监控程序）模式对系统进行分区。通过这种模式和额外的虚拟化功能，低复杂度的虚拟机监视器变得可行。然而，对于安全世界的保护，Cortex-A9没有任何改进。

也就是说，TrustZone的安全属性在很大程度上取决于SoC，而不是ARM CPU内核的修订。基于Cortex-A15的SoC可以为安全的世界提供更多的灵活性（例如响应NS位的更多外设）。然而，我们还没有彻底检查那些SoC供应商特定的实现。

ARM虚拟化扩展的功能是什么？

在现有CPU模式下面有一个新的CPU权限级别（“Hyp”模式），仅在非安全模式下才支持。

存在于ARM体系结构的前几代的虚拟化孔已经针对Hyp模式进行了修复。因此，在其他模式下执行时，所有特权指令都将陷入Hyp模式。因此，架构已经通过陷阱执行模型的方式变得完全可虚拟化。

陷阱和执行模型主要允许在VMM之上执行未修改的客户操作系统。然而，当客户OS以高速率执行特权操作时，例如当中断控制器清除中断时，该模型具有固有的性能惩罚。为了减轻这些影响，已经介绍了硬件支持，以有效避免管理程序的频繁干预。

特别地，可以通过使用新的虚拟IRQ控制器（vIRQ）设备来加速虚拟中断的处理。虚拟机管理程序可以在正常中断控制器的客户物理位置向客户机OS提供vIRQ。因此，客户端将始终与vIRQ设备交互。当客户操作系统清除中断时，管理程序不会涉及。然而，虚拟机中断的注入完全由管理程序完成。由于在一个CPU上的（多个）虚拟机的调度在管理程序中实现，所以无法直接将设备中断分配给虚拟机。因此，为虚拟机指定的每个设备中断将通过管理程序进行跳转。

Cortex-A15通过向虚拟机监视器提供有用的信息，有助于仿真内存映射设备寄存器。除了程序计数器和故障地址之外，VMM接收解码的指令和访问类型。这减轻了VMM访问访客存储器（获取指令）的需要，并简化了指令解码。

为了支持多个虚拟机，引入了物理到主机物理地址转换，这是一种类似于VT-x的扩展页表（EPT）的机制。因此，客体物理存储器变得完全可虚拟化。此功能附带了一种新的页表格式，对于客体虚拟到客体物理映射，它是可选的，并且对于客体物理到主机物理映射是强制性的。除了支持客体物理到主机物理映射之外，新格式总共支持超过4GB的RAM（每个VM，可用RAM的数量仍然受32位寻址的限制）。感谢标记的TLB，存在从客户虚拟到主机物理映射的快速路径。

总线外设（即，显示控制器使用主机 - 物理地址）发出的DMA访问没有虚拟化。如果客户操作系统包含设备驱动程序，则客人必须使用主机 - 物理地址与设备进行交互。例如，提供给设备的DMA缓冲区的地址不能被指定为客体物理地址。因此，在一般情况下，DMA使用的设备不能直接传递给客户机OS。管理程序必须拦截对这些设备的访问才能翻译这些地址。

没有DMA保护。将需要额外的每个设备MMU。这样的每个设备MMU的存在取决于SoC。

指定给客户操作系统中运行的设备驱动程序的IRQ始终由管理程序处理，管理程序通过向vIRQ设备注入虚拟中断来响应IRQ。因此，每个中断都带有在客户机操作系统和管理程序之间切换上下文的开销。然而，这种开销在实践中的相关性是不确定的。

有关ARM虚拟化扩展的更多信息以及创建基于Cortex-A15的虚拟机监视器的过程，请参考 Prashant Varanasi 的优秀文档 “在ARM上的OKL4中实现硬件支持的虚拟化”。

TrustZone如何帮助安全地存储秘密？

隐藏来自非安全世界的外设和内存是TrustZone的一个关键特性。TrustZone没有定义哪些外围设备和内存受到这种机制的影响。这是由SoC供应商掌握的。例如，飞思卡尔i.MX系列的SoC带有完全位于芯片上的RAM和ROM资源。因此，有关这些资源的总线交易在芯片的布线处不可见。通过声明这些资源可以由安全世界独占地访问，在这些资源中存储和处理的信息对于安全软件堆栈保持私有。

也就是说，每个SoC在为任一世界的访问分配或分配存储资源方面具有不同的特征。因此，这个问题没有一般答案。

TrustZone如何促进安全引导？

作为使用TrustZone进行安全引导的前提条件，运行在安全环境中的代码必须以安全的方式进行引导，这是SoC特有的。例如，i.MX系列提供了可以用于安全地引导安全世界的高保证引导（HAB）功能。或者，安全软件可以在生产时被固定在芯片内部闪存或ROM中。例如，诸如Pandaboard等低成本ARM开发板的流行系列具有固定的ROM引导代码，在启动u-boot引导加载程序之前，实现了几个超级调用并切换到非安全模式。因为不能绕过内部ROM代码，所以在这种设备上引导的任何系统都无法访问保存到安全世界的设备资源。

假定安全的世界以安全的方式引导，非安全的操作系统的加载程序就可以通过密码测量来验证非安全操作系统的引导映像的完整性。在Genode在安全环境中运行的情况下，这样的功能可以在用户级VMM组件内实现。

如果SoC缺少修复安全世界的引导代码的方法，即使平台配备了TrustZone技术，安全引导也无法实现。

当使用Genode作为安全操作系统时，SoC应该提供足够的内存来保护安全的世界。早期的平台，如三星S3C6410，只有几个KiB的安全RAM和ROM被排除。