ARM安全架构及其发展趋势

安全之安全(security²)博客目录导读

---

目录

一、Trustzone安全架构的背景知识

二、Arm安全架构简介和发展趋势

三、ARM Trustzone的安全架构介绍

四、Arm虚拟化、VHE的介绍

五、ARM S-EL2 安全虚拟化的介绍

六、CCA/RME技术简介

---

说明：本文为转载文章，已经获得原文作者授权

作者：周贺贺 Baron，十年手机安全/芯片安全开发经验，多家商用TEE部署经验，CSDN知名博主，欢迎大家关注(csdn:代码改变世界ctw)代码改变世界ctw_CSDN博客主页

背景：其实在很多年前，网上是几乎没有Trustzone、TEE、ATF相关文章的，哪怕英文的都很少。后来，大概是在2016年左右，出现了一篇强哥(顾永强)大佬的文章，这简直就是详解Trustzone安全架构的典范；接着就是2017帅峰云的一本黄皮书，也详细介绍了相关的技术。本人在2020年也写了一篇详解，今年(2023年)打算再重新写一篇，主题为讲解和描述“Arm安全架构及其发展趋势”，欢迎大家提出宝贵意见。

一、Trustzone安全架构的背景知识

我们先看背景知识。关于Trustzone的发展有以下时间点：

• 2002年：Arm在这一年就号称支持Trustzone技术了，也就是说，Trustzone技术已经发展22年了。

• 2008年：这一年Arm出了Arm Trustzone白皮书。前面引言中提到的两位大佬的文章，有一部分也是参考的这个白皮书。本文的最后，我会略加“批判”参考这类白皮书写出的文章。(trustzone white paper – ARM Trustzone安全白皮书百度网盘下载, 密码:1234)

• 2013年：第一个支持Trustzone技术的产品问世。据说很多厂商当时都蒙了。
  值得一提的是，2012年，Arm安全事业部就独立出来成立了Trustonic，主要是做Trustzone架构下的TEE OS。国内的一些厂商也号称在这一年开始研究Trustzone技术，所以2012年是一个关键的时间点。

• 2015年：国内部分的手机厂商，已经支持TEE（也就是支持了Trustzone技术）。到了2016年，Android VTS也出了强制标准，规定要过VTS必须要有TEE，要上指纹也必须要有TEE，所以从这一年开始，Trustzone/TEE技术迅猛发展，也几乎在一夜之间迅速普及，在2017年已经成为手机标配。

• 2018年：Arm又推出好多新的安全架构的技术、安全feature技术，同时也推出了各种各样的标准规范。所以安全、安全架构在Arm架构中得到了快速发展。

• 2021-2023年: 在这几年中，Trustzone/TEE技术已经在进军汽车行业，相信用不了几年，也能成为汽车行业的标配。

Trustzone作为ARM安全架构的一部分，于 2008 年 12月 ARM 公司第一次 发布Trustzone 技术白皮书。

2013 年 Apple 推出了第一款搭载指纹解锁的 iPhone：iPhone 5s，用以保证指纹信息安全的 Secure Enclave 技术深度定制了 ARM trustzone 架构，这大概是 Trustzone 技术第一次走进大众视线。到如今 Trustzone 技术已经成为移动安全领域的重要基础技术。也许您不了解它的原理，但它一直默默为您守护您的指纹信息，账户密码等各种敏感数据。如下也列出了一张在Trustzone架构下的指纹框图，这也是这些年(2015-至今)比较流行的一张软件框图。

基本就是Android APP--->famework--->Hal--->Linux driver--->然后控制硬件，画各种框图也基本都是从顶层画到最底层。而到了Trustzone/TEE的技术背景之下，就变成了Android APP--->famework--->Hal--->CA--->TA--->secure driver-->然后控制硬件，画图都变成了从非安全画到安全，从左边画到右边。

二、Arm安全架构简介和发展趋势

在进行阐述之前，我们需要先思考两个问题：

• 什么是Trustzone安全架构？什么是Arm安全架构？

• Trustzone是一种架构、aarch64也是一种架构、armv8也是一种架构。如何理解？

以上两个问题，本文不cover，请大家自行理解，如果实在理解不了，可以评论区留言或私信。

我们知道，在这些年中，整个市场发生了翻天覆地的变化，从最初的仅仅是为了打电话的功能手机、播放音乐的MP3/MP5，到一次比一次酷炫的智能手机，从PC机互联网到移动终端互联网，再到各种各样的共享产品(共享单车)。曾经的PC时代、曾经的Android APP时代、曾经的互联网时代、曾经的共享时代，再到现在的大数据时代、人工智能时代、电动汽车时代(自动驾驶、人工智能)。以上一切的变化，从底层技术来说，其实就是移动终端领域、物联网IOT等领域的技术在一次又一次的进步，这些新的技术在进步的同时，市场的各种各样的需求也对它们提出了各种各样的安全需求。所以无论是Trustzone安全架构，还是Arm安全架构都是在飞跃发展的。

其实我们若是观察Arm的产品线，也不难发现，他们在这些年重点发展的一些领域（高性能计算、低功耗、安全），安全是一个很大的方向。以下我也为大家总结了Arm安全架构的发展路线。

• Trustzone ：在前面的背景中已经和大家介绍过了，Trustzone不是一个硬件，也不是一个软件，它是"Arm安全架构"的一种，是一种技术，一种规范，一种标准设计。目前发展已经非常成熟，商用化落地也非常成熟。

• 虚拟化和VHE ：其实在Arm的定义中，虚拟化也是属于Arm安全架构的一部分。在这几年的汽车电子、Android的PKVM等的推动下，各种各样的操作系统技术不断涌现，该技术也得到广泛应用。

• S-EL2（安全虚拟化）：不用说，这更是Arm安全架构的一部分。在2018年Armv8.4就提出了安全虚拟化，然而光有架构设计出现，就是不见其core IP产品。直至2021年出现的V1（armv8.4）core IP，2021年出现了armv9的core ip，在这些core IP中才是真正支持了安全虚拟化。然后光有支持了安全虚拟化的core IP的产品出现，但一直不见具体的上市产品。在2021年的下半年出现在Arm TrustedFirmware的hafnium，算是推动了该安全虚拟化架构的发展。所以在2022年/2023年很多厂商都已经在开始集成hafnium了。

• CCA机密计算、RME安全架构 ：这也是随着Armv9问世，一起出现的新的Arm安全架构。注意只是架构支持了RME，号称Armv9.4才支持，不过至今还未出现armv9.4的core IP产品。在此架构下，引入了一堆新的概念，虽然号称兼容Trustzone技术，是Trustzone技术的延续，但也推翻了Trustzone技术下的一些安全组件。在此架构的技术下，更多强调的是低特权等级与高特权等级之间的隔离技术，说白了就是hypervisor也探知不到VM或APP的数据。这种架构的技术，也许更适合云服务器之类的产品。现在已经有很多厂商在研究该项技术了。相信在未来的几年内，我们会看到此类的产品。

三、ARM Trustzone的安全架构介绍

从上文我们已经知道， ARM Trustzone不具体指一个硬件，也不是一个软件，而是一个技术架构，在支持ARM Trustzone的SOC中，各个模块需要按照Trustzone的技术说明进行设计，只有各个模块的设计都考虑了Trustzone，那么整个大系统的产品才能再去谈安全。如下便展示了一个支持Trustzone架构的SOC Sample设计。

其中：

• (1)、AMBA-AXI总线支持Trustzone, 增加了标志secure读和写的信号线：AWPROT[1]和ARPROT[1]
  说明: 事实上AMBA-APB、AMBA-AHB，也都有看secure access和non-secure access。

• (2)、processor支持Trustzone，在ARM Core系统寄存器中有SCR_EL3.NS比特位，这样ARM Core发起的操作就可以被标记“是以secure身份发起的访问，还是以non-secure身份发起的访问”

说明：部分Master也需要像Arm core那样支持安全标识。

• (3)、TZPC，用于配置apb controller的权限(或者叫secure controller)，例如将efuse(OTP Fuse)配置成安全属性后，那么processor以non-secure发起的访问将会被拒绝，非法的访问将会返回给总线一个错误。

  说明：可能是因为这类设计比较简单，TZPC一般都是SOC厂商自己定义和设计的,他们也不会称之为TZPC,一般就叫secure controller、secure master。Arm官网也查不到有这类IP，除了能够查到一个BP147 TZPC的文档（该文档诞生于2002年），2008年的Arm Trustzone白皮书上也提到了该概念。在前面引言部分中，我提到的强哥/帅老板的文章或书籍中也重点提到了这个概念，所以网上大多数介绍Trustzone技术的文章也都是提到这个TZPC。这里我再划重点提一下，那个2002年的文档不用看了哈，已经不符合当前的技术设计了。具体的TZPC设计资料，也没有公开的，大家如果真想知道，可以和自己公司的ASIC同事去探讨，看他们是怎样设计的。

• (4)、TZASC，在DMC之上增加一个memory filter，现在一般都是使用TZC400，或由SOC厂商自己设计一个这样的IP，或叫MPU，或叫firewall，或集成在DMC内部，它的作用一般就是配置DDR的权限。如果配置了DDR中某块region为安全属性，那么processor以non-secure发起的访问将会被拒绝。
  说明：在早期很多厂商都是直接用TZC400 IP，可能当时的业务需求也是比较简单的，最大配置8个安全region就足够满足需求了。如今，Trustzone/TEE技术在汽车领域、非手机行业的领域也得到了广泛的使用，8个安全region可能已经不能满足需求了，另外在这些行业中对firewall也提出了更多的差异化需求，所以现在我见过的很多厂商都抛弃了TZC400 IP，而自研自己的firewall IP了。也许是它的ASIC RTL设计本身也不难吧。

• (5)、MMU/TLB/Cache对Trustzone技术的支持

  MMU就分为了Non-secure EL0&1 Translation Regime 和 Secure EL0&1 Translation Regime，即normal world和secure world侧使用不同的Translationn Regime，其实就是使用不同的TTBRx_ELn寄存器，使用不同的页表，使用不同的物理地址空间。

  在MMU管理的页表entry中，也有一个NS比特描述是output address是安全地址还是非安全地址。在TLB entry中，有NS(Walk)比特位，表示该条entry是在安全状态下的地址翻译，还是在非安全状态下的地址翻译。在TLB entry中，也有NS安全状态的比特，表示output address是安全地址还是非安全地址。在cache的TAG中，也有NS安全状态比特位，表示该地址的缓存是来自安全物理地址还是非安全的物理地址。

  以上特点，单个理解或记忆都是非常容易的，但是如何串起来就很难理解了。下面也为大家展示了一个全局的MMU/TLB/Cache安全比特框图。

  

• (6)、gicv2/gicv3，在gicv2/gicv3的版本中，都天然支持Trustzone技术。 以gicv3为例，将中断划分成了group0、secure group1和non-secure group1.。在软件的使用场景下，分别表示“想给ATF处理的中断”、“想给TEE处理的中断”、“想给REE处理中断”。

  

四、Arm虚拟化、VHE的介绍

Arm虚拟化技术旨在支持基于Arm架构的处理器上运行多个虚拟机，每个虚拟机都可以运行独立的操作系统和应用程序。这些虚拟机之间是相互隔离的，运行在一个称为虚拟化监视器（Virtualization Monitor）或Hypervisor的软件层之上。虚拟化技术为数据中心、云计算、物联网等场景提供了灵活性和资源利用率的优势。

Arm虚拟化技术主要包括两个扩展：

• Virtualization Extension (VE)：VE是Arm虚拟化的基础，提供了虚拟化模式下的新指令和功能，用于支持虚拟化监视器和虚拟机之间的交互。

• Virtualization Host Extensions (VHE)：VHE是Arm虚拟化技术的进一步改进，它的目标是优化虚拟化的性能和效率。

  说明：Arm的VHE(Virtualization Host Extensions)技术是在Arm v8.1体系结构中引入的一项改进，它旨在简化虚拟化监视器（Hypervisor）的设计，并提高虚拟化性能。主要特点包括：
  （1）改进虚拟机切换的速度：VHE技术通过优化虚拟机切换的过程，减少了在虚拟机间切换的开销，从而提高了虚拟化性能。
  （2）降低Hypervisor复杂性：VHE技术简化了Hypervisor的设计，使Hypervisor更容易实现和维护。
  （3）支持低延迟虚拟中断：VHE技术改进了虚拟中断处理，减少了虚拟中断的延迟，提高了虚拟机的响应性能。

其实吧，以上的两个虚拟化技术VE和VHE，对应的就是type-1 hypervisor和type-2 hypervisor，两类技术的发展都比较流行，都是趋势。

例如风靡于汽车电子的QNX Hypervisor+QNX OS，它是一种type-1 hypervisor的技术，在今后可能会变得越来越流行。

例如在Android阵营中的PKVM，它是一种type-2 hypervisor的技术，在今后也许会将它推为强制。

五、ARM S-EL2 安全虚拟化的介绍

ARM S-EL2（Secure EL2）是ARM体系结构中的一种安全扩展，用于提供安全虚拟化支持。

在这种安全虚拟化架构下，有了secure EL2，也有了secure hypervisor概念，在这种架构下就可以做到多个TEE OS并存，专业的说法叫多个Secure Partition并存。Secure Partition不一定是TEE OS，也可以是一个固件，一段C语言代码、一段汇编代码。

随着整个大系统中的硬件、软件越来越复杂，各个固件/组件之间的通信或协作也成为一个难题。2018年，Arm推出了FF-A的一个标准规范，该规范定义了一系列的资源管理、接口通信标准。目前在常用的开源软件中(uboot、EDK2、Linux Kernel、ATF、xen、hafnium、optee)也都支持了该规范。如下图所示，便展示了在FF-A标准规范下，给optee组件之间通信带来的一些变化。

六、CCA/RME技术简介

RME是Arm Confidential Compute Architecture（Arm CCA）的硬件组成部分。RME也是Arm安全架构的一部分。RME可以动态地将资源和内存转移至一个新的受保护的地址空间，这个地址空间无法被高特权的软件或TrustZone固件所访问。借助于这个地址空间，Arm CCA能够构建被称为Realms的受保护的执行环境。

Realms让应用程序或Virtual Machine（VM）等低特权软件能够保护自己的内容。Realms还能抵御来自使用高特权级别软件（如操作系统或hypervisor）的攻击。高特权的软件仍需要负责为Realms分配和管理资源，但是，这些高特权软件无法访问Realms的内容或者影响其执行流程。

RME也能动态地将内存转移到Realms的受保护的地址空间。有了RME，给TrustZone软件实体使用的内存可以动态变化。

在RME安全架构的大背景下，arm core不再是2种安全状态，变成了四种安全状态：

• 安全状态

• 非安全状态

• Realm状态

• Root状态

在这四种的安全状态下，我们的软件架构也发生了剧烈的变化，这样更适合CCA的需求。

以下展示一张比较全局的CCA/RME软硬件架构图。

从这张图中，我们可以看到各种新的变化，例如：

• GPC的概念

• MPE的概念

• Completer-side的概念

除此之外，还有很多很多要考虑的,例如：

• ARM Core支持了4种安全状态，那其它的Master是否需要支持？

• AMBA总线呢，是否支持4种安全的address？

• MMU/TLB/Cache ？

• gicv4？

• SMMU？

在整个ARM CCA/RME安全架构的设计中，以上都有被考虑到的。有关更多的内容，请持续关注并留言。我们下一期再见。

*注：文中的部分图片分别来自qnx官方文档、linaro官方文档、Arm官方文档。