赞
踩
目录
说明:本文为转载文章,已经获得原文作者授权
作者:周贺贺 Baron,十年手机安全/芯片安全开发经验,多家商用TEE部署经验,CSDN知名博主,欢迎大家关注(csdn:代码改变世界ctw)代码改变世界ctw_CSDN博客主页
背景:其实在很多年前,网上是几乎没有Trustzone、TEE、ATF相关文章的,哪怕英文的都很少。后来,大概是在2016年左右,出现了一篇强哥(顾永强)大佬的文章,这简直就是详解Trustzone安全架构的典范;接着就是2017帅峰云的一本黄皮书,也详细介绍了相关的技术。本人在2020年也写了一篇详解,今年(2023年)打算再重新写一篇,主题为讲解和描述“Arm安全架构及其发展趋势”,欢迎大家提出宝贵意见。
我们先看背景知识。关于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-->然后控制硬件
,画图都变成了从非安全画到安全,从左边画到右边。
在进行阐述之前,我们需要先思考两个问题:
什么是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的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虚拟化技术旨在支持基于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(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组件之间通信带来的一些变化。
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官方文档。
Copyright © 2003-2013 www.wpsshop.cn 版权所有,并保留所有权利。