Arm 机密计算架构引入了 Realm Management Extension (RME) ,它支持称为Realm的新型可证明隔离环境。该环境建立在 TrustZone Normal 和 Secure 世界之上,另外还有两个世界,每个世界都有自己的安全状态和专用的物理地址空间。RME 还允许内存在运行时在世界之间移动,而新硬件会检查每个内存访问,阻止世界之间的隔离边界不允许的访问。
安全状态
RME 建立在 Arm TrustZone 技术之上。 TrustZone 是在 Armv6 中引入的,提供以下两种安全状体
- Secure state
- Non-Secure state
下图显示了 AArch64 中的两个安全状态以及通常在每个安全状态中找到的软件组件:
该架构将在安全状态下运行的软件与在非安全状态下运行的软件隔离开来状态。这种隔离实现了一种软件架构,其中受信任的代码在安全状态下运行,并且不受非安全状态下的代码的影响.
RME 扩展了这个模型,并提供了以下四种安全状态:
- Secure state
- Non-secure state
- Realm state
- Root state
下图显示了启用 RME 的 PE 中的安全状态,以及这些安全状态如何映射到异常级别:
维持现有的安全状态,是提供了与现有信任区用例的向后兼容性。这些还可以升级用例,以利用RME添加的新特性,如dynamic内存分配。
Realm state构造受保护的执行环境,称为Realm 。重要的是,RME扩展了TrustZone中引入的隔离模型。
该体系结构为以下状态提供隔离:
- Non-secure 和 realm states隔离的安全状态
- Non-secure and Secure states隔离的Realm状态
这种隔离模型提供了一种软件体系结构,在该体系结构中,软件处于安全和可靠的状态,各个状态间相互不信任。
使用RME,EL3将脱离安全状态并进入其自身的安全状态(称为root)。RME将EL3与所有其他安全状态隔离开来。EL3承载平台和初始引导代码,因此必须由软件在非安全、安全和安全领域中信任状态。因为这些安全状态彼此不信任,所以EL3必须在它自定义的安全状态中。
2.1 Controlling the current Security state
当前安全状态由异常级别和SCR_EL3的组合控制管理。
EL3现在是它自己的根安全状态。在EL3中,安全状态为始终为root,并且没有其他异常级别可以处于root状态。
当处于较低的异常级别(如异常级别0、异常级别1和异常级别2)时,安全状态由SCR_EL3中的NS和NSE字段控制,如下表所示:
Root态没有编码。在异常级别3中,当前安全状态始终为根,不考虑SCR_EL3。{NSE,NS}值。
在异常级别3中,SCR\_EL3的当前值 {NSE,NS}用于控制某些操作。例如,在EL3发出转换查找缓冲区(TLB)无效指令时,对于较低的异常级别来收,SCR_EL3 {NSE,NS} 用于控制操作应用的安全状态。这里其实和之前SCR_EL3的原理类似,NS是在引入RME之前处理的。
2.2 Moving between Security states
在安全状态之间移动的原则继承自TrustZone。更改安全性状态,执行必须通过EL3,如下图所示:
图中的更改安全状态过程遵循以下步骤:
- 在Realm状态和SCR_EL3中开始执行。{NSE,NS}设置为0b11。软件执行一个SMC 同步指令,该指令导致异常被带到异常级别EL3.
- 处理器进入EL3,现在处于根状态,因为EL3始终处于根状态,不过异常来自Realm域,SCR_EL3 {NSE,NS}拥有同样的安全状态。处于EL3的软件更改SCR_EL3{NSE,NS}到所需安全状态的对应值,并执行异常返回(ERET)。
- ERET导致从异常级别3退出。当离开异常级别3时,SCR_EL3 {NSE,NS}控制输入的安全状态。在此图中,安全状态为非安全状态(Hypervisor)。
在vector registers、通用寄存器和系统绝大绝大多数寄存器存在一个副本。在安全状态之间移动,以及保存和恢复寄存器上下文,是软件的责任,而不是硬件的责任。保存和恢复此寄存器上下文的软件是通过Monitor下软件来完成(和ARM V8模式相同)。
3 Physical addresses
除了两个安全状态外,TrustZone还提供以下两个PA空间:
- 安全的物理地址空间
- 非安全物理地址空间
这些单独的PA空间构成信任区隔离保证的一部分。非安全状态不能访问安全PA空间中的地址。这种隔离意味着存在保密性和安全性,保证属于安全状态的数据的完整性。
RME扩展了该保证,以支持以下PA空间:
- 安全的物理地址空间
- 非安全物理地址空间
- Realm领域物理地址空间
- Root物理地址空间
架构限制了在每个安全状态下可以看到哪些PA空间。下表显示了在每个安全状态下可以访问的PA空间:
当文档引用一个物理地址时,前缀用于标识所使用的地址空间, 例如:
- SP:0x8000表示安全PA空间中的地址0x8000
- NSP:0x8000表示非安全PA空间中的地址0x8000
- RLP:0x8000表示Realm域PA空间中的地址0x8000
- RTP:0x8000表示根PA空间中的地址0x8000
架构上,每个示例都是一个独立的内存位置。这意味着SP:0x8000和RTP:0x8000被视为不同的物理位置。所有四个位置都可以存在于启用RME的系统中,尽管在实践中,这不太可能。
3.1 Virtual address spaces
为了支持新的安全状态,RME为Realm引入了以下页表转换机制
- Realm EL1&0翻译机制
该机制包括两个虚拟地址(VA)区域,类似于非安全区域EL1&0页表机制。 这一页表受制于第二阶段页表转换 - Realm领域异常级别2和0转换机制
此机制包括两个VA区域,类似于安全异常级别2和0页表机制。 - Realm领域异常级别2和2转换机制
此机制包括单个VA区域,类似于安全异常级别2页表机制。
下图显示了领域状态转换机制:
对于所有领域转换机制,任何转换为非安全物理地址的地址都是被视为永远不会执行。
3.2 Root state translation regime
根状态中仅存在异常级别3。这意味着根有一个单一的翻译机制状态,这是EL3页表机制。这种页表机制在RME之前就存在了,但以前被认为是安全状态的一部分。
RME包含对EL33转换机制的以下更改:
- 虚拟地址可以在四个物理地址空间中的任意一个空间转换为物理地址
- 任何转换为非安全、安全或领域物理地址的地址都被视为不执行
- MMU工作台只能访问根PA空间
- 当MMU在EL3禁用时,所有输出地址都在根PA空间中
注:异常级别3继续使用异常级别3页表,该页表具有一一对应VA空间特性。
3.3 Controlling output PAS
当通过MMU,转换虚拟地址时,获取对应的PA地址,由以下条件组合控制,包含:
- 当前的安全状态
- 当前异常层级
- 页表
- 系统寄存器
软件可用的控件因页表而异。现在我们来看看,在每个安全状态和页表的控制下。
3.4 Non-secure state translation regimes
下图显示了非安全页表转换机制的概述
非安全状态只能访问非安全PA空间。
在此图中,TTD表示转换表描述符(页表)。
3.5 Secure state translation regimes
安全状态可以访问安全和非安全PA空间,如下图所示:
对于安全EL1和0转换机制中,NS bits 用于页表Stage阶段1转换过程中。
在EL2,VTCR_EL2和VSTCR_EL2上被使用,用于映射每个IPA空间到公共PA空间。
注意:在安全状态下,RME不会更改这些控制。
3.6 Realm state translation regimes
Realm机密领域状态可以访问机密领域和非安全PA空间,如下图所示:
Realm领域EL0/1转换机制具有单一的IPA空间。因此,数据中没有NS位,用于EL0/1第一阶段翻译表条目商。
Realm领域阶段2 TTD包括一个NS位,用于映射到Realm领域或非安全PAS。这这意味着,与安全状态不同,领域状态在第二阶段需要体现在页表上。
Realm领域EL2翻译机制和领域EL0/2翻译机制具有第一阶段NS位,用于控制输出PA空间。
TrustZone引入了转换表项中的NS位,以允许安全状态选择对应输出PA空间。在安全状态下,NS位编码如下:
- NS=0:安全
- NS=1:不安全
对于RME,NS字段也用于领域EL0/1第二阶段和领域EL2/0第一阶段的翻译
- NS=0:realm
- NS=1:不安全
3.7 Root state translation regimes
根状态可以访问所有PA空间,如下图所示:
异常级别3第一阶段翻译机制在翻译表中有两个位,NS和NSE,用于控制输出PA空间的条目。这些编码与用于 SCR_EL3 {NSE,NS},除了有根的编码外,如下表所示:
3.8 Impact on TLBs and caches
TLBs缓存最近使用的翻译。TLB条目需要记录条目属于哪个的页表。在TLB查找期间,只有当条目中的翻译制度与请求的翻译制度匹配时,才能返回条目。这将防止一个安全状态使用TLB,返回其他安全状态的条目。
下表显示了一个简化TLB示例,记录了翻译制度:
类似地, cache line需要记录关联的PA空间,如下图所示:
作者:代码改变世界ctw
原文链接:https://blog.csdn.net/weixin_42135087/article/details/123469717
推荐阅读