TEE硬件切换原理
文章目录
什么是TrustZone
TrustZone 硬件架构
正常世界和安全世界的互动
在安全世界和正常世界之间切换
集群中的安全性
安全调试
参考文档
什么是TrustZone
TrustZone 是 Arm A-profile 架构中安全架构的名称。 在 Armv6K 中首次引入 TrustZone，在 Armv7-A 和 Armv8-A 中也得到支持。
Arm TrustZone是一种针对基于 ARM Cortex 处理器系统的嵌入式安全选项的系统范围方法。
ArmTrustZone也可以说是一种嵌入式安全技术，它从硬件级别开始，通过创建两个可以同时运行在单个核心上的环境：一个安全世界和一个正常世界。
Normal 世界(正常世界)运行丰富的软件，这些软件通常包括庞大的应用程序或者复杂的操作系统(例如Linux)，可能还有一个管理程序。虽然可以努力保护它们，但攻击表面太大意味着它们更容易受到攻击。
Trusted 世界(安全世界)运行比正常世界更小且简单的软件(例如TEE)。通常，TEE包括几个由轻量级内核托管的可信服务。受信任的服务提供了诸如密钥管理等功能。这些软件有一个相当小的攻击表面，这有助于减少对攻击的脆弱性。
TrustZone 旨在形成一个圆形。 作为用户和开发人员，我们想要 Normal 世界的丰富功能集和灵活性。 同时，我们希望在受信任的世界中使用更小、更受限制的软件堆栈来实现更高程度的信任。 TrustZone 为我们提供了两者，提供了两个环境，它们之间具有硬件强制隔离。
TrustZone 硬件架构
TrustZone为系统设计人员提供了一种帮助提升系统安全性的方法，即使用TrustZone安全拓展和安全外设。低级程序员应该理解TrustZone体系结构对系统提出的设计要求，即使他们不使用安全特性。
ARM Security Extensions模型允许系统开发人员划分设备的硬件和软件资源，这些资源要么存在于安全世界，要么存在于非安全世界。
正确的系统设计可以确保不能从正常世界访问安全世界资产。
安全设计将所有敏感资源置于安全世界中，理想情况下，运行强大的软件可以保护资产免受各种可能的软件攻击。
《The ARM Architecture Reference Manual》使用术语安全和不安全来指代系统安全状态。
非安全状态并不自动意味着安全漏洞，而是正常操作，因此与正常世界相同。
通常，正常世界和安全世界之间存在主和从关系。
只有当操作系统允许通过由安全监控调用(SMC)指令启动的机制执行安全世界时，才会执行安全世界中的代码。
Secure monitor的作用是提供一个"看门人"，管理安全世界和正常世界的切换。在大多数设计中，它的功能和传统的操作系统上下文切换类似，首先要确保核心正在离开的世界状态得到安全保存，其次处理器切换到的世界状态被正确恢复。
Secure monitor架构的增加意味着单个物理内核可以执行来自正常世界和安全世界的代码,每个世界都可以让步或调用另一个世界，尽管这取决于可以配置为只能由安全世界访问的产生中断的外围设备的可用性。例如，可以使用安全定时器中断来保证安全世界的一些执行时间。此类外围设备是否可用具体取决于平台设计人员打算支持的安全级别和用例。
Secure monitor是一个安全关键组件，因为它提供了两个世界之间的接口。出于稳健性原因，Secure monitor代码应在禁用中断的情况下执行。 编写一个可重入的monitor会增加复杂性，并且并没有比简单的设计带来更多好处。
或者，可以使用更接近协作多任务的执行模型，尽管就每个世界可以访问的资源而言，安全世界独立于普通世界，但每个世界都可以让位于另一个世界以启用代码执行。
像固件或任何其他系统软件一样，安全世界中的软件必须尽量减少对系统其他部分的影响。例如，通常应避免消耗大量执行时间，除非执行普通世界请求和预期的某些操作。非安全中断应尽快传递到Normal world 。这有助于确保Normal world 世界软件的良好性能和响应能力，而无需大量移植。
内存系统被一个额外的位划分，该位伴随着外围设备和内存的物理地址。该位称为 NS 位，指示访问是安全的还是非安全的。该位被添加到所有内存系统事务中，包括缓存标签以及对系统内存和外围设备的访问。NS 位可以为 Secure 和 Normal 世界提供不同的物理地址空间。
在正常世界中运行的软件只能对内存进行非安全访问，因为无论在正常世界转换表中设置了什么，内核总是在正常世界生成的任何内存事务中将 NS 位设置为 1。（PS：内核怎么知道是安全世界还是正常世界？）在安全世界中运行的软件通常只进行安全内存访问，但也可以使用其转换表条目中的 NS 和 NSTable 标志对特定内存映射进行非安全访问。
尝试对标记为安全的缓存数据执行非安全访问会导致缓存未命中。
尝试对标记为安全的外部存储器执行非安全访问通常会向内核返回错误响应。
非安全系统试图访问安全内存没有任何错误提示。
EL3 有自己的转换表，由转换表基址寄存器 TTBR0_EL3和转换控制寄存器 TCR_EL3 管理。 在安全世界中只允许第一阶段的翻译，并且没有TTBR1_EL3。EL1 转换表寄存器不在安全状态之间存储，因此作为Secure monitor上下文切换操作的一部分，必须为每个世界保存和恢复 TTBR0_EL1、TTBR1_EL1 和 TCR_EL1的值。
这使每个世界都可以拥有一组本地转换表，其中安全世界映射对普通世界隐藏并受到保护。安全世界转换表中的条目包含 NS 和 NSTable 属性位，它们决定特定的访问是否可以访问安全或非安全物理地址空间。
安全和非安全条目可以在缓存和 TLB 中共存。在世界之间切换时无需使缓存数据无效。普通世界只能生成非安全访问，因此只能命中标记为非安全的缓存行，而安全世界可以生成安全和非安全访问。如果安全状态在访问之间发生变化，这可能需要一些缓存管理。
TLB 中的条目记录了哪个世界生成了特定条目，虽然非安全状态永远不能对安全数据进行操作，但安全世界可以将 NS 行分配到缓存中。此外，针对每个异常级别分别启用和禁用缓存。缓存控制对于两个世界是独立的，但不是独立于所有异常级别，因此 EL0 永远不能直接启用或禁用缓存，并且 EL2 可以覆盖非安全 EL1 的行为。
正常世界和安全世界的互动
典型的系统具有轻量级内核或可信执行环境 (TEE)，托管服务，例如安全世界中的加密服务。这与Normal 世界中的丰富操作系统交互，该操作系统可以使用 SMC 调用访问安全服务。通过这种方式，Normal world可以访问服务功能，而没有暴露密钥的风险。
通常，应用程序开发人员不直接与安全扩展、TEE 或可信服务交互。相反，它们使用由 Normal world 库提供的高级 API，例如 authenticate() 。该库由与受信任服务相同的供应商（例如信用卡公司）提供，并处理低级交互。
下图以流的形式显示了这种交互，用户应用程序调用 API 进行适当的操作系统调用，该调用传递到驱动程序代码，然后通过安全监视器将执行传递到 TEE。
通常需要在安全世界和普通世界之间传递数据
例如，在安全世界中，您可能有一个签名检查器。普通世界可以使用 SMC 调用请求安全世界验证下载更新的签名。
安全世界需要访问普通世界使用的内存。安全世界可以使用其转换表描述符中的 NS 位来确保它使用非安全访问来读取数据。
这很重要，因为与包相关的数据可能已经在缓存中，因为普通世界执行的访问地址标记为非安全。安全属性可以被认为是一个额外的地址位。如果内核使用安全内存访问来尝试读取包，它不会命中缓存中已经存在的非安全数据。
如果你是普通世界的程序员，一般来说，你可以忽略安全世界中发生的事情，因为它的操作对你是隐藏的。一个副作用是中断延迟会略微增加。安全世界可以完全阻塞，因此如果发生请求安全内核执行的中断，这可能会阻塞普通世界的中断，但与典型操作系统的整体延迟相比，这种增加很小。这种类型的服务质量问题取决于安全世界操作系统的良好设计和实施。
在安全世界和正常世界之间切换
借助 ARMv7 安全扩展，软件使用监控模式在安全和非安全状态之间切换。此模式是安全状态中其他特权模式的对等模式。 在 ARMv8-A 处理器中，AArch32 相当于 ARMv7-A。
对于 ARMv8 架构，当 EL3 使用 AArch32 时，系统的行为与 ARMv7 相同，以确保完全兼容，因此安全状态下的所有特权模式都被视为处于 EL3。
AArch32 的安全模型如下图所示。 在这个场景中，EL3 是 AArch32 来提供一个安全的操作系统和监视器。
下图是EL3执行AArch64提供Secure Monitor时的安全模型。EL1 用于安全操作系统。EL3 使用 AArch64 时，EL3 级别用于执行负责在 Non-secure 状态和 Secure 状态之间切换的代码。
根据 AArch32，安全状态 EL1 和 EL0 与非安全状态 EL1 和 EL0 具有不同的虚拟地址空间。这允许将来自 AArch32 32 位架构的安全端代码用于具有 64 位操作系统或在非安全端运行的管理程序的系统中。
随着正常世界执行停止和安全世界执行开始，它们之间的上下文切换通过执行安全监视器 (SMC) 指令或硬件异常机制（例如中断或异步中止）发生。ARM 处理器有两种中断类型，FIQ 和 IRQ。
以将异常和中断重定向到 EL3 的控制形式明确支持安全中断，与当前的 DAIF 字段无关。但是，这些控件仅区分主要中断类型：IRQ、FIQ 和异步中止。更详细的控制需要将中断过滤到安全和非安全组中。 有效地做到这一点需要 GIC 的支持，它为此目的提供了明确的设施。
一个典型的用例是将 FIQ 用作安全中断，方法是将安全中断源映射为中断控制器中的 FIQ。相关的外设和中断控制器寄存器必须标记为仅安全访问，以防止正常世界重新配置这些中断。这些安全 FIQ 中断必须路由到处于安全执行状态的处理程序。
使用安全扩展的实现通常有一个轻量级的可信内核，在安全世界中托管安全服务，例如加密。完整的操作系统在正常世界中运行，并且能够使用 SMC 指令访问安全服务。
通过这种方式，普通世界可以访问服务功能，而不会冒将密钥材料或其他受保护数据等安全资产暴露于普通世界中执行的任意代码的风险。
集群中的安全性
集群系统中的每个核心都具有相同的安全特性。集群中任意数量的核都可以在任何时间点在安全世界中执行，并且核能够相互独立地在世界之间转换。
寄存器控制正常世界代码是否可以修改Snoop控制单元(SCU)设置。类似地，在集群中分发优先级中断的GIC必须配置为了解安全问题。
安全调试
安全系统还控制调试供应的可用性。 您可以通过完整的 JTAG 调试和跟踪控制为正常和安全软件世界配置单独的硬件，这样就不会泄露有关受信任系统的信息。 您可以通过安全外围设备控制硬件配置选项，也可以硬连线并使用以下信号控制它们：
安全特权侵入式调试启用 (SPIDEN)：JTAG 调试。
安全特权非侵入式调试启用 (SPNIDEN)：跟踪和性能监视器
参考文档
1.Security in an ARMv8 System
2. ARM文档搜索
3. Arm TrustZone explained
4. Trusted Firmware
5. ARM的安全启动—ATF/TF-A以及它与UEFI的互动
————————————————
版权声明：本文为CSDN博主「知否,知否」的原创文章，遵循CC 4.0 BY-SA版权协议，转载请附上原文出处链接及本声明。
原文链接：https://blog.csdn.net/qq_24835087/article/details/122636928
一、TEE介绍
随着Face ID、指纹识别、5G、AI等技术的发展，移动互联网已经悄然根植于现代生活中，伴随着日常生活的移动化，移动终端中存储的各种敏感信息日益增多，移动终端自身的安全性面临着巨大的挑战。
移动端系统运行的环境叫做REE（Rich Execution Environment），在其中运行的系统叫做Rich OS（Operating System），如最常见的Android系统，但是REE是一个开放的环境，容易收到恶意软件的攻击，比如敏感数据被窃取、数字版权被滥用、移动支付被盗用等。因此，2010年7月GP（Global Platform，全球平台组织）提出了TEE(Trusted Execution Environment)可信执行环境的设计。TEE是一个与REE并存运行的独立执行环境，它具有其自身的执行空间，比Rich OS的安全级别更高，为Rich OS提供安全服务，如指纹的录入比对、支付校验认证等操作。本文主要介绍的是TEE基本原理和架构以及TEE与指纹识别技术的结合。
二、TEE基本原理
TEE是在Arm Trustzone技术上建立起来的一套可信执行环境，通过硬件和软件隔离，实现normal world和secure world，也就是REE和TEE。TrustZone 技术是基于 ARM 架构系统级别层次的对 service 以及 device 进行保护的一项技术, 为了支撑该保护技术, ARMV8 本身支持名为 secure mode 的模式，用来区分 normal mode， 其通过设置 Secure Configuration Register 系统寄存器来使能该模式的支持，该寄存器的最后 1 bit 为 0 的话，则表示当前 CPU 处于为 secure mode，如下图所示，并且 ARM 本身支持将系统资源配置成 secure 状态，通过操作 TZPC 控制寄存器可以将系统总线、内存、DMA、cache 等资源配置成 secure 态，配置成 secure 态之后，normal 端运行的程序无法访问其硬件资源。
三、TEE软件框架
Tbase的软件架构符合GPD TEE的基本构架，整个软件架构分为REE和TEE两部分，通过Monitor Mode进行安全和非安全状态切换。REE部分是指normal world，在REE中运行的系统和应用分别是Rich OS和CA。而TEE部分是指secure world，分别对应Trusted OS和TA。
REE中的系统结构：
CA（Client APP）对应一些上层应用，比如指纹采集、支付应用等，通过调用TEE Client API实现与TEE环境的交互。
REE Communication Agent为TA和CA之间的消息传递提供了REE支持
TEE Client API是REE中的TEE驱动程序提供给外部的接口，可以使运行在REE中的CA能够与运行在TEE中的TA交换数据。
TEE中的系统结构：
TA（Trusted Application）是TEE中完成特定功能的应用。由于TEE中完成计算因此具有较高的安全性。每一个TA在REE中有一个或者多个对应的CA，在REE环境中可以通过调用CA的接口，将信息传送到TEE环境中执行TA，完成对应功能然后返回计算结果。
TEE Communication Agent是可信操作系统的特殊组成部分，它与REE Communication Agent一起工作，使TA与CA之间安全地传输消息。
TEE Internal Core API是TEE操作系统提供给TA调用的内部接口，包括密码学算法，内存管理等功能。
Trusted Device Drivers可信设备驱动程序，为专用于TEE的可信外设提供通信接口。
Shared Memory是一块只有CA和TA可以访问的一块安全内存，CA和TA通过共享内存来快速有效传输指令和数据
CA与TA交互流程如下：CA首先调用TEE Client API触发系统调用，进入REE的操作系统内核态，根据CA调用的参数找到对应的REE驱动程序，REE驱动程序通过调用SMC汇编指令进入Monitor模式，并将处理器切换到安全内核状态，进入安全模式。切换进入TEE以后，CA的服务请求通过总线传到TEE侧，然后TEE OS通过TEE Internal API调用对应的TA，最后TA运行结束后将运行结果和数据返回给CA，执行完以后回到TEE内核态调用SMC汇编指令进入Monitor切回REE环境。
四、TEE软件流程
TEE技术日益发展成熟，例如Trustonic公司的Tbase，得到了GlobalPlatform授权认可的商业产品；Linaro开源的OPTEE；Samsung的Mobicore，主要应用在Samsung手机上；Qualcomm的QSEE，在高通CPU的手机平台上有广泛应用；华为的HW-iCOS,主要服务华为手机。
下面将介绍TEE的软件交互流程，使用GlobalPlatform组织定义的GP API接口。
CA与TA通信需要使用下列接口完成整个会话流程：
CA侧接口如下：
TEEC_InitializeContext:对变量Context进行初始化配置，用来建立CA和TEE的联系，向TEE申请共享内存地址用于存放数据。
TEEC_OpenSession:建立一个CA和TA间的session，用于CA和UUID指定的TA进行通信，是CA连接TA的起始点。
TEEC_InvokeCommand:依靠打开的session，将传送命令请求给TA，并将必要的指令执行参数一并发送给TA。
TEEC_CloseSession:关闭session，关闭CA和TA之间的通道。
TEEC_FinalizeContext:释放Context，结束CA与TEE的连接。
TA侧接口：
TA_CreateEntryPoint:为CA建立接入点，使得TA可以被CA调用。
TA_DestroyEntryPoint:移除CA的接入点，结束TA的功能。
TA_OpenSessionEntryPoint:建立CA与TA之间的通讯通道，作为CA连接TA的起点。
TA_CloseSessionEntryPoint:关闭CA与TA的通讯通道
TA_InvokeCommandEntryPoint:接收CA传送的指令和参数，并在这TEE侧执行。
在 GP 标准中，CA 要与 TA 进行通信，需要建立如下所示的软件逻辑流程：
1）首先CA 需要与 Trusted OS 之间建立一个 Context，以后此 CA 与 TEE 环境的所有通信均基于此 Context。
2）然后 CA 会向 Trusted OS 申请与请求的 TA 建立一个 Session。
3）CA 与 TA 之间的 Session 建立完成后，CA 就可以向 TA 发送 Command。
4）Command 及其参数会通过共享内存的方式传递，TA 从共享内存中获取到 CA 的请求以及请求参数。
5）TA 在 TEE 环境下执行处理，得到的处理结果重新填充到共享内存中，CA 通过共享内存就可以获取到处理结果。
6）获得处理结果后，如不需要进一步请求，则由 CA 发起关闭 Session 的请求，Trusted OS 回收 TA 相关资源，最后 CA 发起销毁 Context 的请求，完成一次完整交互。
五、TEE应用举例
由于tee有较高的安全性的同时，硬件成本和开发成本相对都不是很高，tee技术被广泛应用于移动设备中，下面将介绍在Android智能手机上电容指纹技术与TEE的结合。
1. 指纹软件框架
如下图是Android上的指纹软件框架，REE环境下主要分为APP，Framework，HAL和linux kernel。APP主要负责指纹录入解锁调用逻辑，Framework主要负责回调HAL层相关函数，HAl层负责和硬件以及指纹TA交互。而TEE主要是指纹TA，指纹TA负责控制指纹sensor和执行指纹算法相关函数。
Fingerprint TA:主要进行基本操作，比如控制finger sensor采图，特征提取，指纹算法处理等操作。
finger CA:负责与Fingerprint TA进行通信，发送指令，向Fingerprint HAL提供REE与TEE的通信接口。
Secure SPI driver：TEE与指纹sensor通信的SPI安全驱动
finger lib:指纹算法库，主要是对指纹图像特征提取比对等算法实现
Fingerprint HAL:指纹hal，调用CA的接口向TA下发指令，同时通过Fingerprint Device Driver实现对GPIO,Power，INT等管脚和功能控制。
Fingerprint service:指纹framework，回调hal层相关函数，控制指纹录入解锁等流程
App：指纹最上层的代码，主要是负责指纹录入解锁调用逻辑
2. 指纹录入流程
Hal中指纹的录入流程为：指纹sensor初始化（begin enroll）->采图(do capture)->录入（do enroll)->结束录入(do enroll)->指纹模板存储（store template）。对应TA的录入流程为：指纹sensor init（begin enroll）->采图（capture image）->将采集的指纹数据传输回TA->录入(do enroll)->结束录入(end enroll)->模板加密存储到secure memory（encrypt）。
HAL中主要进行的是与TA交互，给TA发送指令，同时还会对指纹硬件进行操作，比如指纹sensor上下电等。TA收到CA的command，则需要处理敏感数据和一些安全性要求高的动作，如TA通过secure spi控制指纹sensor采图，图像传输，图像处理，图像比对，模板存储等。这些都是在TEE环境下进行操作的，所以指纹解锁是一种相对比较安全的解锁方式。
参考资料：
[1]Global Platform specification and Technology Document
[2]http://kernel.meizu.com/2017/08/17-33-25-tee_fp.html
[3]https://www.jianshu.com/p/c238bfea3e46
长按关注
————————————————
版权声明：本文为CSDN博主「内核工匠」的原创文章，遵循CC 4.0 BY-SA版权协议，转载请附上原文出处链接及本声明。
原文链接：https://blog.csdn.net/feelabclihu/article/details/114422107