(ROC-RK3568-PC) 裸机10_TEE环境

参考：ARMv8-a架构简介

ARMv8-a架构简介

Large memory：
        应用对内存的需求可能超出32-bit架构所能支持的最大内存（4G），需要寻址更大内存。

Execution state：
        指有AArch64和AArch32两套运行环境，分别执行64-bit和32-bit指令集。软件可以在需要的时候，切换Execution state。

Exception level：
        AArch64最大的改动，就是引入 EL0~El3 中个运行级别的概念。

Security model：
        主要是引入 trustZone,  将代码运行环境从硬件层面划分为安全和非安全两个环境。

Virtualization：
        从硬件层面支持虚拟化技术，如果用过安卓上的 VMOS Pro之类的应用感觉会非常明显。
        运行在VMOS Pro里面的虚拟机，反应速度可以跟一台物理手机一样快。

除了兼容旧版和支持更大内存，新引入的技术都是为了更好的隔离运行环境。

最简单的隔离，硬件系统至少需要增加：一个特权级别 和 MMU(内存映射技术)。

        1). 让操作系统内核运行在特权级别，让普通应用运行在普通级别
        2). 内核可以读写所有可用的物理内存
        3). 内核通过 MMU 给应用分配假的内存地址
        4). 内核管理应用的真假地址的映射表，让应用读写假地址时能自动翻译成真地址

这种增加 EL1 + MMU 的方式可以实现以下隔离：
        内核和应用间的隔离
        应用和应用间的隔离

这种隔离使得系统内运行的多个应用没办法相互破坏，也使得应用出错卡死不会影响到系统的正常运行，让系统变得更稳定，更可靠。
 

如果要在单台物理电脑上运行多个操作系统，并且速度还不至于特别慢——即硬件虚拟化技术，
就得多加入 一个特权级别 和 SMMU——EL2 + SMMU，用来隔离物理机器上不同的操作系统
当然虚拟化，不只是简单的内存虚拟化，还有DMA外设，其它各种外设的虚拟化，实际很复杂，
负责这些工作的是VMM(也叫Hypervisor)，运行在EL2。
更多虚拟化内容可参考：https://segmentfault.com/a/1190000022797518

AArch64系统级体系结构之VMSA

理论上，EL0 + EL1 + EL2  加上 两级MMU，已经可以实现所有的隔离了，
为何ARMv8还要引入EL3?  大致有两个原因：
        1). 因为 ios 和 android 有不安全的时候，比如被 root 了，此时内核环境就不安全了
             这就需要另一个隔离的环境，当然可以使用VMM+虚拟机的方式，
             但这种在移动设备中硬性引入VMM的方式，又使系统变得很复杂，而且效率低下。
        2). 因此必须引入隔离的虚拟机环境，而ARM又不想使用EL2来实现这个虚拟机环境，
总不能吃了现有的VMM软件的市场，它也吃不了， 因为太过复杂，毕竟软件不是ARM的本行。
于是 ARM 引入EL3, 在硬件层实现了一个小的半虚拟机环境。

并且把它称为 ARM Trustzone， 也将硬件分成了安全和非安全环境。

EL2是为了实现市场上开放的虚拟机技术(VMM)
EL3是为了实现单设备安全的私有的硬件虚拟机(TrustZone)

注：2022年01月26号 好像有新闻说 ARMv8.4 硬件支持多个虚拟机了。

rk3568上电时， 默认是 AArch64 + EL3 + 无硬件虚拟机， 拥有最高权限。
此时， 可以通过设置特定的寄存器来启用硬件虚拟机，并对两个虚拟机进行硬件资源分配，
通常的，
将拥有最高权限的虚拟机，称为   安全世界(secure workd)，留作TEE，资源需求少
权限稍低的虚拟机，           称为非安全世界，分配90%以上的硬件资源，做为REE

TEE: Trusted Execution Environment ，资源比较少，独享私密安全相关的硬件
REE: Rich Execution Environment， 资源比较富集的运行环境，运行安卓、IOS等

TEE 一般运行的都是些小内核，资源占用少，也不需要支持硬件虚拟化技术，
故而 TEE 没有也用不到 EL2！

全流程安全启动

市场上的手机，一般在 bootrom 内会集成一个生产厂家的公钥，
用以对手机存储中的 bootloader 做身份检验，只有厂家私钥签名过的 bootloader 才会校验成功，
才会加载，通过一级级的校验，可以实现整个启动流程的安全性，
因为如果启动流程都不可信，那硬件虚拟机中TrustZone的安全，根本就无从谈起。

而开源的开发板则不会做这种校验，即便有也会把bootrom中集成的公私 对应的私钥给公布出来

指纹 TEE - 魅族内核团队

[原创]浅析安全启动（Secure Boot）-智能设备-看雪论坛-安全社区|安全招聘|bbs.pediy.com

EL3层的代码， 既是 loader 又是TEE + REE两套虚拟机环境的管理者，
所以 EL3也被叫做 Secure Monitor， 本身不属于任何虚拟机，不分安全和不安全(AArch64)，
因为 TEE 和 REE 的隔离性，运行于REE中的代码想调用TEE中的功能，
得通过 smc 指令 中断到EL3层， 由EL3层转发调用。

EL3层完成这些工作的代码，一般叫做　ATF(Arm Trusted firmware)：
GitHub - ARM-software/arm-trusted-firmware: Read-only mirror of Trusted Firmware-A

上面是一份 很有参考价值 的官方源码。

上图是典型的 AArch64 商业应用情况，
上电时， EL3 的 ATF 划分出REE和TEE 并实现全流程安全启动
        接着加载引导 TEE 中的 Trusted OS (开源的op-tee，或者厂家自己写的小内核) , 
        再加载引导 REE 中的 Rich OS(android, ios, linux)

上图是个完整的流程，前面两篇笔记的 3568tpl，就运行于BL2(EL3 TEE)。
OP-TEE 参考: OP-TEE Documentation — OP-TEE documentation documentation

指纹识别的安全性
常规系统一旦被root，本身就已经不安全了， 不晓得加了TEE又有什么用？
或者说，安卓被root的情况，TEE如何保护支付相关的验证流程？

在被root的情况下， 支付软件是可以被hook的，通过hook支付软件验证密码地方，
让它总是返回验证成功，即胡乱输入的密码也能hook响应为密码是正确的，
试想这种情况TEE又如何保护支付软件不会被hook？

答案是TEE并不会保证安卓被root后，应用被hook的情况不会发生！
TEE保证的只是指纹信息不被泄漏、以及保证指纹比对结果可信。

支付安全如何实现？
对于密码验证，答案是：验证密码正确与否的代码不在客户端，而在服务器端！
对于指纹验证，答案是：有区分 -> 本地指纹认证 和 远程指纹认证。
        首先，不可能只依赖本地验证
        其次，远程指纹认证的流程如下：
        1). 设备出厂前进行以下操作：
        让TEE生成非对称密钥对，其中的私钥不可导出，无人可见，加密存储，
        公钥则通过双向HTTPS安全上传至公钥库服务器（比如微信的TAM），
        2). 设备到客户手上，先让TEE做指纹录入(指纹不可导出，无人可读取，加密存储），
        当要验证指纹时：
        让TEE进行进行指纹比对，比对结果 CheckRlt 用私钥加密后再传给REE端，
        REE端将 CheckRlt 上传至自己可控的后台，在后台服务器中调用共享服务器上的公钥来
        来做解密， 如果解密成功才能看到本次指纹验证的结果！
整个过程， 私钥、指纹图像，都由TEE访问操作，完全黑匣子状态，外界都不可读取，外界可读取的只有公钥和加密后的指纹比对结果。

至于TEE是否可信，依赖于SecureBoot 中的证书信任链，倘若SecureBoot流程的证书也来自可控的公钥库服务器，那么TEE也就是可信的，

所以，支付业务的公司(微信、支付宝)，都将公钥库服务器握在自己手里，
微信的公钥库服务器对外开放验证接口让第三方应用使用，支付宝的也有指纹SDK，有些芯片厂商也提供SDK。

离线支付的场景：
        付款方单方离线的场景，如支付宝、微信
        双离线支付，如数字人民币（仅限小额交易场景）

参考：

 双离线支付概念 - jiftle - 博客园

Tencent SOTER

手机厂商如何保证指纹安全的？兼谈供应链 - 知乎

如何在复杂业务场景中优雅实现Android指纹验证？ - 知乎

TEE概述&ARM Trustzone硬件架构基础介绍

至于如何避免REE侧安全？
1). 不允许安装不可信的第三方应该，避免系统被root后应用被hook
2). 及时修补漏洞，避免系统被root后应用被hook
3). 安装扫毒软件，避免系统被root后应用被hook
4). 不随便启用开发者模式，不乱插USB口，避免系统被root后应用被hook
5). 应用尽量做足运行环境的检测
6). TEE增加UI进行支付提醒

在古代，支付密码泄漏后，REE侧系统被root后支付应用被hook的情况多可怕？
第三方应用可以调用支付应用的转账接口，并自动填入密码，然后自动确认转账！
现在因为有TEE+独享的指纹传感器硬件，再加上手指按住传感器代替输入密码的过程，
相比于古代，要安全得多了。

上面这一小段，不是这篇笔记的主要内容。

如何用代码分配两个硬件虚拟机的资源，可参考：
        TZPC(TrustZone Protection Controller) - 简书

        TEE概述&ARM Trustzone硬件架构基础介绍

        ARM Trusted Firmware分析——启动、PSCI、OP-TEE接口

CPU 的每个 core 都虚拟出 secure 和 Non-secure 两种模式，当 core 为 Non-secure 时，Secure Configuration Register 的 NS bit 置为 1，为 secure 模式时，NS bit 置为 0。NS bit 默认为 0，也就是说，CPU 上电后每个 core 都默认为 secure mode。

软件中断指令：
svc 用于陷入el1，供el0层代码请求el层的服务，常用于内核向应用层提供系统调用
hvc 用于陷入el2
smc 用于陷入 el3
AArch64系统级体系结构之编程模型（3）- 异常

SVC：默认情况下SVC产生supervisor call，同步异常目标级别为EL1,使得运行EL0的软件可以
        调用EL1下的操作系统或软件的接口

HVC：如果实现了EL2，默认情况下HVC产生hypervisor call，同步异常目标级别为EL2
        注：HVC指令在EL0和secure EL1没有定义

SMC：
        默认情况下SMC产生Secure monitor Call,同步异常目标级别为EL3
        注：SMC指令在EL0未定义

• Supervisor Call (SVC)指令允许用户模式程序请求操作系统服务。
• Hypervisor Call (HVC)指令使客户操作系统能够请求Hypervisor服务。
• Secure monitor Call(SMC) 指令使普通世界能够请求安全世界服务。