TEE 实现原理

分类于 ， 阅读次数： Disqus： 本文字数： 3.6k 阅读时长 ≈ 13 分钟

TrustZone

如何区分当前访问状态是安全状态下的访问还是非安全状态下的访问？

CPU发出的地址都是虚拟地址，需要经过页表转换才能得到物理地址，其中在pte页表中低12bit（针对4k大小的页表）为控制位，用来控制页表的访问属性，也就是说在页表建立的时候就确定了访问状态是安全状态还是非安全状态，其pte低12bit如下：

这里的bit 5 NS bit（Non-secure bit）：用来指定访问的内存地址是安全映射的还是非安全映射的。

只有当ARM核处于安全状态（NS bit=0）时发送到系统总线（AXI）上的读写操作才会被识别为安全读写操作，对应TEE侧的数据资源才能被访问。反之，当ARM核处于非安全状态（NS bit=1）时，ARM核发送到系统总线上的读写操作请求会被作为非安全读写操作，安全组件会根据对资源的访问权限配置来决定是否响应该访问请求。

💡 NS bit的设置是通过SMC指令触发异常进入EL3安全监视器中设置的，即Normal World通过SMC调用进入Security World，将NS bit置0，Security World通过SMC指令进入Normal World，安全监视器将NS bit置1

如何划分安全区域和非安全区域以及如何拦截非安全状态下的安全地址访问？

DDR（TZASC）：

TrustZone地址空间控制组件（TrustZone Address Space Controller，TZASC）是AXI总线上的一个主设备，TZASC能够将从设备全部的地址空间分割成一系列的不同地址范围。在安全状态下， 通过编程TZASC能够将这一系列分割后的地址区域设定成安全空间或者是非安全空间。被配置成安全属性的区域将会拒绝非安全的访问请求。

使用TZASC主要是将一个AXI从设备分割成几个安全设备，例如off-Soc、DRAM等。ARM的动态内存控制器（Dynamic Memory Controller，DMC） 并不支持安全和非安全分区的功能。如果将DMC接到TZASC上，就能实现DRAM支持安全区域和非安全区域访问的功能。需要注意的是，TZASC组件只支持存储映射设备对安全和非安全区域的划分与扩展，但不支持对块设备（如EMMC、NAND flash 等）的安全和非安全区域的划分与扩展

一个完整的系统必然会有片外RAM，对片外 RAM的隔离是通过TZASC组件实现的，ARM本身的DMC可以将DRAM分割成不同的区域，这些区域是没有安全和非安全分类。将DMC与TZASC相连 后再挂到总线上，通过对TZASC组件进行编程可以将DRAM划分成安全区域和非安全区域。当主设备 访问DRAM时，除需要提供物理地址之外，还会发送PROT信号。TZASC组件首先会判定主设备需要访问的DARM地址是属于安全区域还是非安全区域，然后再结合接收到的PROT信号来判定该次访问是否有效。如果PROT信号为非安全访问操作， 且访问的DRAM地址属于安全区域，则TZASC就不会响应这次访问操作，这样就能实现DRAM中安全区域和非安全区域的隔离。

SRAM和ROM（TZMA）：

TrustZone内存适配器组件（TrustZone Memory Adapter，TZMA）允许对片上静态内存（on-SoC Static Memory）或者片上ROM进行安全区域和非安全区域的划分（仅有安全访问可以配置TZASC的寄存器）。TZMA支持最大2MB空间的片上静态RAM的划分，可以将2MB空间划分成两个部 分，高地址部分为非安全区域，低地址部分为安全区域，两个区域必须按照4KB进行对齐。分区的具体大小通过TZMA的输入信号R0SIZE来控制，该信号来自TZPC的输出信号TZPCR0SIZE。即通过编程TZPC可以动态地配置片上静态RAM或者ROM的大小。

外设地址（APB-to-AXI桥）：

TrustZone同样能够保护外围设备的安全，例如：中断控制、时钟、I/O设备，因此Trust-Zone架构还 能用来解决更加广泛的安全问题。比如一个安全中断控制器和安全时钟允许一个非中断的安全任务来监控系统，能够为DRM提供可靠的时钟，能够为用户提供一个安全的输入设备从而保证用户密码数据不会被恶意软件窃取。

AMBA3规范包含了一个低门数、低带宽的外设总线，被称作外设总线（Advanced Peripheral Bus，APB），APB通过AXI-to-APB桥连接到系统总线上。而APB总线并不具有安全状态位，为实现 APB外设与TrustZone技术相兼容，APB-to-AXI桥将负责管理APB总线上设备的安全。APB-to-AXI桥会拒绝不匹配的安全事务设置，并且不会将该事务请求发送给外设。

TrustZone保护控制器组件（TrustZone Protection Controller，TZPC）是用来设定 TZPC DECPORT信号和TZPC R0SIZE等相关控制信号的。这些信号用来告知APB-to-AXI对应的外设是安全设备还是非安全设备，而TZPCR0SIZE信号用来控制TZMA对片上RAM或片上ROM安全区域大小的划分。

TZPC包含三组通用寄存器 TZPCDECPROT[2：0]，每组通用寄存器可以产生8 种TZPCDECPROT信号，也就是TZPC最多可以将 24个外设设定成安全外设。TZPC组件还包含一个TZPCROSIZE寄存器，该寄存器用来为TZMA提供分区大小信息。TZPC组件的接口示意如图所示

AXI 访问流程

cpu发出了虚拟地址访问，这个地址要经过AXI总线到达外设地址，但是这个地址访问仍然是没有安全状态的，TZASC或者TZMA或者APB-to-AXI桥是如何判断访问级别的呢？

TrustZone技术通过对总线进行扩展增加安全位读写信号线来实现。除了对总线进行扩展还需要对MMU、Cache、TLB以及其他组件进行扩展都是增加了安全bit。

AXI总线上安全状态位的扩展

AXI写数据的过程如下图所示：

地址通道携带描述被传输数据性质的控制信息。

读数据的过程如下图所示：

每一个通道都拥有自己的VALID与READY信号用于实现握手，其中VALID信号表示通道的地址、数据或控制信息已经可用，而READY信号则表示接收方已准备好接收信息。

AXI信号描述

写地址通道信号：

信号名 来源 描述
AWID 主设备 写地址ID，该信号用于标识写地址组
AWADDR 主设备 写地址，写突发操作中第一次数据传输的地址
AWLEN 主设备 突发长度，这个字段标识每次突发传输的传输次数
AWSIZE 主设备 突发大小，这个字段表示每次突发传输的大小
AWBURST 主设备 突发类型，包括突发类型和突发大小信息，该字段决定了每次突发传输时地址的计算方法
AWLOCK 主设备 锁定类型，提供关于传输时原子特性的额外信息
AWCACHE 主设备 存储器类型
AWPROT 主设备 保护类型
AWQOS 主设备 服务质量，即每次写传输的QoS标识符，仅AXI4支持
AWREGION 主设备 区域标识符，允许一个从设备的单个物理接口用作多个逻辑接口，仅AXI4支持
AWUSER 主设备 用户定义信号，可选
AWVALID 主设备 主设备给出的地址和相关控制信号有效
AWREADY 从设备 从设备已准备好接收地址和相关的控制信号

读地址通道信号：

信号名 来源 描述
ARID 主设备 读地址ID，该信号用于标识读地址组
ARADDR 主设备 读地址，读突发操作中第一次数据传输的地址
ARLEN 主设备 突发长度，这个字段标识每次突发传输的传输次数
ARSIZE 主设备 突发大小，这个字段表示每次突发传输的大小
ARBURST 主设备 突发类型，包括突发类型和突发大小信息，该字段决定了每次突发传输时地址的计算方法
ARLOCK 主设备 锁定类型，提供关于传输时原子特性的额外信息
ARCACHE 主设备 存储器类型
ARPROT 主设备 保护类型
ARQOS 主设备 服务质量，即每次读传输的QoS标识符，仅AXI4支持
ARREGION 主设备 区域标识符，允许一个从设备的单个物理接口用作多个逻辑接口，仅AXI4支持
ARUSER 主设备 用户定义信号，可选
ARVALID 主设备 主设备给出的地址和相关控制信号有效
ARREADY 从设备 从设备已准备好接收地址和相关的控制信号

以上只列出了部分读地址通道信号和写地址通道信号。

而我们关心的是AWPROT和ARPROT信号。

  • ARPROT[2:0]定义了读访问的访问权限。
  • AWPROT[2:0]定义了写访问的访问权限。

其中，信号定义如下：

AxPROT 值 功能
[0] 0/1 非特权访问/特权访问
[1] 0/1 安全访问/不安全访问
[2] 0/1 数据访问/指令访问

这里又多了一个特权访问和非特权访问？官方手册是这么描述的：

AXI提供特权访问还是非特权访问的信息，但是具体怎么用，看各控制器的设计了。没有查到更多信息，暂时先不管这个特权访问了。

详细可参考： https://www.lzrnote.cn/2021/10/08/axi总线总结/

http://www.gstitt.ece.ufl.edu/courses/fall15/eel4720_5721/labs/refs/AXI4_specification.pdf

ATF（ARM Trusted Firmware）

该固件统一了ARM底层接口标准，如电源状态控制接口（Power Status Control Interface，PSCI）、安全启 动需求（Trusted Board Boot Requirements， TBBR）、安全世界状态（SWS）与正常世界状态 （NWS）切换的安全监控模式调用（secure monitor call，smc）操作等。ATF旨在将ARM底层的操作统一使代码能够重用和便于移植。

ATF启动流程：

ATF的源代码共分为bl1、bl2、bl31、bl32、 bl33部分，其中bl1、bl2、bl31部分属于固定的固件，bl32和bl33分别用于加载TEE OS和REE侧的镜像。整个加载过程可配置成安全启动的方式，每一个镜像文件在被加载之前都会验证镜像文件的电子签名是否合法。

ATF主要完成的功能如下：

  • 初始化安全世界状态运行环境、异常向量、 控制寄存器、中断控制器、配置平台的中断。
  • 初始化ARM通用中断控制器（General Interrupt Controller，GIC）2.0版本和3.0版本的驱动初始化。
  • 执行ARM系统IP的标准初始化操作以及安全扩展组件的基本配置。
  • 安全监控模式调用（Secure Monitor Call， SMC）请求的逻辑处理代码（Monitor模式/EL3）。
  • 实现可信板级引导功能，对引导过程中加载的镜像文件进行电子签名检查。
  • 支持自有固件的引导，开发者可根据具体需求将自有固件添加到ATF的引导流程中。

Trusted Firmware提供了满足ARM安全规格的参考代码，包括TBBR(Trusted Board  Boot Requirements)和SMCC。

SMC Dispatcher：处理非安全世界的SMC请求，决定哪些SMC由Trusted Firmware在EL3处理，哪些转发给TEE进行处理。

Trusted Firmware处理PSCI任务、或者SOC相关工作。一个典型的基于TrustZone系统软件调用栈关系图：

  • 安全世界的Trusted OS提供一系列安全服务，比如key管理或DRM。非安全世界应用需要使用这些服务，但是又无法直接使用。通过使用一些库中API来获取这些能力，比如libDRM.so。
  • 这些库和Trusted service之间通信往往通过message queue或者Mailbox。他们之间通信所用内存往往被称为WSM(World Shared Memory)。这些内存必须能够被Trusted service和库访问，这就意味着这些内存是非安全内存。
  • 应用通过库发送一个请求到Mailbox或message queue，然后触发内核中TrustZone驱动。
  • TrustZone驱动负责和TEE部分交互，包括为message queue申请内存和注册这些内存。由于安全和非安全运行在两个虚拟地址空间，所以无法通过虚拟地址进行通信。
  • TrustZone驱动通过调用SMC进入安全状态，控制权通过EL3的Secure Monitor传递到TEE中的TEEOS。TEEOS从message queue内存中获取内容由Trusted service进行处理。
    • Trusting the message：由于message是从非安全世界传递的，所以需要安全世界对这些内容进行一些认证。
    • Scheduling：对于PSCI类型快速处理并且不频繁请求，进入EL3处理完成后退出到非安全状态。对于一些需要TOS处理的任务，不能被非安全中断打断，避免造成安全服务不可用。
    • OP-TEE：OP-TEE内核运行在S.EL1，可信应用运行在S.EL0。

OP-TEE

OP-TEE 是依靠 Arm TrustZone 技术作为底层硬件隔离机制而实现的一种TEE OS。

TEE OS功能

  • 进程管理
  • 内存管理
  • 安全存储
    • RPMB File System
    • REE File System
  • 加密引擎
    • 对称加密（AES，DES）
    • 非对称加密（RSA，ECC）
    • 摘要（MD5，HASH，HMAC）
  • 软件隔离
    • 进程隔离
    • 内存隔离
    • 数据隔离
  • 真随机数
  • 安全时钟
  • 硬件秘钥及派生
  • ...

TEE应用

  • DRM
    • Widevine
    • PlayReady
    • Netflix
  • CAS
    • Nagra
    • Verimatrix
    • Irdeto
    • NSK
    • VO
  • 秘钥烧录
  • 无线显示
  • 生物识别
  • 移动支付
  • 飞控系统
  • 重置保护
  • ...

参考文献

https://github.com/carloscn/blog/blob/master/README.md
物联网终端应用TEE的一些思考