为何ARMv8-a架构要引入EL3呢

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外设，其它各种外设的虚拟化，实际很复杂，

理论上，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中集成的公私 对应的私钥给公布出来



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

EL3层完成这些工作的代码，一般叫做　ATF(Arm Trusted firmware)：

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



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



上图是个完整的流程，前面两篇笔记的 3568tpl，就运行于BL2(EL3 TEE)。

指纹识别的安全性
常规系统一旦被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。

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

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

在古代，支付密码泄漏后，REE侧系统被root后支付应用被hook的情况多可怕？
第三方应用可以调用支付应用的转账接口，并自动填入密码，然后自动确认转账！
现在因为有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

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) 指令使普通世界能够请求安全世界服务。