最近看PSA安全技术交流微信群里，有一些做网关、车载，以及智能模组等朋友会聊一些TrustZone技术问题，想学TrustZone，但是不知道如何下手。下面将TrustZone的文档以及学习思路整下方便刚接触TrustZone的朋友学习和查找。

对于做手机、电视和机顶盒的芯片公司来说，大部分朋友对TrustZone已经非常精通了，例如指纹识别、人脸识别、移动支付、数字版权保护、企业应用，TEE-SIM等应用的安全性基本都是通过TrustZone来保护。现在越来越多的IOT，车载设备也开始注重信息安全，今年会越来越多的IOT设备也开始使用TrustZone来增加安全性。

TrustZone是作为Arm架构的安全扩展，也是随着架构的演进来不断的演进，例如Armv8.0-A将Secure Monitor和Secure OS分开大大简化TrustZone的开发难度，到Armv8.4-A时增加了Secure EL2增加了系统安全性和可扩展性，包括GICv1/v2/v3，SMMUv2/v3，TZASC, Security IP, AMBA等都随着TrustZone在向前演进，不过核心机制还是没变，还是CPU有两个安全状态，将系统的资源划分成安全和非安全两部分，通过一些System IP来控制访问权限，类似握手机制，Master和Salve都支持，如果salve不支持，一般需要在salve前面加个wraper来支持。Armv8-M也支持TrustZone，不过今天我们主要介绍时Armv8.x-A的TrustZone。

TrustZone白皮书

这份白皮书非常旧，还是介绍的Arm1176JZ，A8和A9，但是也是很多人学习TrustZone的第一份资料，介绍了什么是资产、攻击、和防御，也介绍了安全的三个要素CIA，也介绍TrustZone的硬件安全架构，包含CPU的安全状态，如何进行切换；MMU， TLB和Cache如何支持TrustZone，不过TLB和Cache算是微架构，不同的CPU上实现的方式也有些不太一样；AXI的AxPROT[1]如何区分是安全访问，还是非安全访问。安全中断也是非常重要的一部分，例如在文档中把FIQ作为安全中断，IRQ作为非安全中断，同时GIC也需要相应的支持；安全调试也是比较重要的一部分，例如通过SPIDEN、SPNIDEN、SUIDEN、SUNIDEN来控制不同的调试权限。也介绍了TrustZone软件架构，例如SMC指令，SecureMonitor，中断处理、上下文切换，以及安全启动。让大家明白TrustZone不是一个IP，是一个系统安全架构，不仅仅是包含hardware，还包含software，也包含了很多system IP。

Trustzone 平台设计文档 TBBR和TBSA

TBBR的全称是Trusted Board Boot Requirements，可以简单理解为安全启动的设计文档。安全启动时设计安全SoC的第一部分，基于不可更改的信任根，安全启动和安全升级非常多样化，我们在做安全SoC设计的时候很难去调研所有场景的安全启动要求，如果软件是多个供应商来参与，那么不同的供应商之间互相不信任，那么设计安全启动时就非常复杂。那么可以参考这个文档，这个文档主要介绍安全启动的流程、证书格式，需要支持的加解密算法、以及密钥强度，能满足GP TEE PP的文档要求，也可以涵盖绝大部分的应用场景，可以大大简化设计的时间。

TBSA的全称是Trusted Base System Architecture，可以简单理解为安全SoC设计的参考，安全是应用来驱动，如果不知道安全场景，对于硬件工程师来说很难去设计安全SoC，例如看总线的安全特性只是多了一个信号，它到底怎么跟安全怎么结合起来，还有OTP到底要留多大，哪些外设要做成安全的，哪些外设要做到动态配置的，安全timer给谁用等，一头雾水。这个文档通过用户隐私、数字版权保护、FIDO，BYOD为例为场景，介绍每个场景下哪些资产要保护，以及是机密性，还是完整性，再往下细分需要哪些软件和硬件支持，以及需要多少资源，这样理解起来就会容易很多，例如文档中会介绍需要哪些外设才能组建一个安全SoC作为参考，例如从CPU、ROM、SRAM、DDR、Fuse、Interrupt、power and clock management、Cryptographic Key，Secure timer、Counter ，Debug，Lifecycle等为例来介绍如何做一个安全SoC，可以简化大家自己摸索的时间。

Trusted Firmware-A

如果用的Armv8-A的CPU的话，还是非常推荐看下Trusted Firmware-A，现在绝大部分的Armv8-A的设备都在用Trusted Firmware-A，有了ATF（Arm Trusted Firmware）后，使用TrustZone也方便了很多。在以前Armv7-A时，很多开发secure OS的公司很痛苦，因为不但要安全OS、安全业务的设计，同时也要兼顾跟平台相关的特性，例如电源管理、安全启动、上下文切换、一些公司私有IP的驱动，如果涉及到多核更加麻烦，往往移植到一个新平台需要花非常大的精力，需要几个月的时间。到Armv8-A以后，有了EL3，可以将跟平台相关、以及通用的特性都可以放到EL3来实现，secure OS可以运行在S-EL1，Arm开发的ATF可以很好解决上面的问题，例如ATF包含了BL1，BL2，BL31，BL32等，可以简单认为BL1是Rom Code运行在EL3，BL2可以理解为Secure bootloader，BL31就是运行在EL3 的Run time services，BL32是运行在EL1的Secure OS，客户也可以替换BL32，换成自己选用的secure os，例如OP-TEE或者商业化的secure os等。ATF可以简单认为是按照TBBR的安全要求来实现了安全启动、安全升级的流程，同时也按照SMC calling covention实现了REE和TEE之间的切换、包括中断处理，按照PSCI实现了power管理，以及为Secure os留了标准的注册接口，让Secure OS更加关注与安全业务，留有标准的注册机制，很容易实现夸平台移植，同时ATF也在不断的向前演进。

OP-TEE

OP-TEE是一个开源Secure OS，也支持32位和64位，现在也有电视，机顶盒、网关设备等在用。如果再Armv8-A的CPU上，是运行在S-EL1，OP-TEE也是符合GP TEE API的规范，主要是三部分组成，一个是optee\_os可以看做是OS的内核，也支持静态TA，也支持User TA, 还有一个是optee\_client是运行REE侧给Client Application 提供接口，还有一个optee\_test可以认为是一些测试用例，包含CA和TA。比较早期是还有一个optee\_linuxdriver，现在用的也比较少了 ，因为Linux主分支已经有了TEE driver。

GP TEE API

比较早期时，TEE的API比较碎片化，目前大多数的Secure OS都跟GP TEE API兼容，例如OP-TEE等，但是也有些secure os会有私有的API，也有些朋友在问TEE和TrustZone什么关系，可以认为TEE是比较泛的安全可执行环境的概念，TrustZone是Arm CPU架构的安全扩展，能够通过TrustZone实现TEE。GP TEE API的内容可以参考GP的官网。

Armv8.4 S-EL2白皮书

如上文所说，安全的需求是不断在变化，TrustZone也随着Arm架构的演进在变化，例如比较早期时，运行在Secure world只是一些安全服务库，主要做安全启动和加解密服务，再后来开始运行一些简单的secure os提供的功能也非常有限，例如安全升级，密钥管理，随着安全应用需求的变化Secure os也在变化，例如开始支持多核，支持AI，支持C++，人脸识别，Secure OS越来复杂，在我们可预见的未来可能有支持多个secure os，或者一个Secure OS + 特性的Secure services，从Armv8.4后secure world也开始支持虚拟化，不仅提高了安全性，也提高了系统的可扩展性。例如目前Secure OS可以访问所有的资源，Secure OS也可以访问的Secure Monitor的memory，有了S-EL2之后，可以通过S-EL2可以限制S-EL1的访问权限，例如Secure OS访问不到ATF的代码，也访问不到REE OS的代码和数据。从可扩展性上也会更方便，例如一些secure services或者secure IP driver 不需要移植到Secure OS上，可以提供给标准的API给secure os来使用，隔离的粒度会更细，做安全认证时也相互独立。

安全不是一成不变的，是安全业务来驱动，影响安全的软件架构和硬件架构，以及CPU和IP的演进，例如现在Android应用已经从32位演进到64位，到64位可以通过Armv8.x的PAC，BTI，以及MTE的技术来提高安全性，具体如何提高，找时间在写。

以上仅是个人看法，如果有任何问题，欢迎随时讨论.