[问答]

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

问答对人有帮助，内容完整，我也想知道答案 0 ARMv8-a架构是由哪些部分组成的呢？为何ARMv8-a架构要引入EL3呢？ 0
2022-3-2 09:12:53　　评论淘帖0 邀请回答您可以邀请以下用户，快速回答问题 × liutiefu 该类别下有 26 个回答。邀请回答 tigerwang711 该类别下有 20 个回答。邀请回答 ze55me 该类别下有 20 个回答。邀请回答杀狼000 该类别下有 19 个回答。邀请回答 zhuzb0754 该类别下有 19 个回答。邀请回答冰箱洗衣机该类别下有 18 个回答。邀请回答 YYXIAO 该类别下有 18 个回答。邀请回答安德森大该类别下有 17 个回答。邀请回答 CDCNKA 该类别下有 17 个回答。邀请回答 jjll652 该类别下有 17 个回答。邀请回答河神大人该类别下有 17 个回答。邀请回答 mede1001 该类别下有 17 个回答。邀请回答 YOYOOO 该类别下有 16 个回答。邀请回答麻酱该类别下有 16 个回答。邀请回答世态薄凉该类别下有 16 个回答。邀请回答熊本熊该类别下有 16 个回答。邀请回答江左盟该类别下有 15 个回答。邀请回答 wang21cj 该类别下有 15 个回答。邀请回答 dfgsdf 该类别下有 15 个回答。邀请回答 szj0213 该类别下有 15 个回答。邀请回答举报名士流相关推荐 • ARMv8架构的两种执行状态分别是什么 5072 • ARMv8 Vector table问题该如何更好地去理解呢 2125 • 探讨一下ARMv8的AArch32 PE模式 6509 • ARMv8-A AArch32主要特性 2297 • ARM **是如何支持并产生安全中断的 4870* • ARM GIC（十一） gicv3架构中的2种安全状态 5624 • 为什么armv8下start汇编中的堆栈指针sp要设置为_start函数地址呢 3226 • 在armv8架构中Arch32切换到Arch64是如何运作的 2097 • 为什么访问ARMV8系统寄存器icc_sre_el2会发生错误呢 2026 • Arm各个exception level都可以访问sp_el0, 这么做的原因是什么？ 1467 1个回答

答案对人有帮助，有参考价值 0 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) 指令使普通世界能够请求安全世界服务。

2022-3-2 15:42:03 评论举报曹玥