ARMv9的RME安全架构介绍

安全之安全(security²)博客目录导读

目录

一、简介

1.1 学习要求

二、安全状态

2.1 控制当前的安全状态

2.2 在安全状态之间切换

三、物理地址

3.1 虚拟地址空间

3.2 Root状态的 Translation Regime

3.3 控制输出PAS

3.4 非安全状态 Translation Regime

3.5 安全状态 Translation Regime

3.6 Realm状态 Translation Regime

3.7 Root状态 Translation Regime

3.8 对TLBs和缓存的影响

四、颗粒保护检查

4.1 颗粒保护表

4.2 颗粒保护检查错误

4.3 颗粒保护错误

4.4 通过物理地址空间转移颗粒

4.5 对缓存的影响

4.6 对TLB的影响

4.7 省略

五、调试、跟踪和分析

5.1 外部调试

5.2 自托管调试

5.3 自托管跟踪和SPE

5.4 性能监控

5.5 分支记录缓冲区扩展

六、SMMU架构

6.1 在RME启用系统中的SMMU

6.2 对RME的SMMU架构的更改

七、系统架构

7.1 主内存保护

7.2 MPAM

7.3 RAS


说明: 本文为转载文章,原文链接ARM精选:Armv9的RME安全架构介绍

一、简介

本文引入了Arm V9-A架构的扩展——Realm Management Extension(RME)。

RME是Arm Confidential Compute Architecture(Arm CCA)的硬件组成部分。RME可以动态地将资源和内存转移至一个新的受保护的地址空间,这个地址空间无法被高特权的软件或TrustZone固件所访问。借助于这个地址空间,Arm CCA能够构建被称为Realms的受保护的执行环境。

Realms让应用程序或Virtual Machine(VM)等低特权软件能够保护自己的内容。Realms还能抵御来自使用高特权级别软件(如操作系统或hypervisor)的攻击。高特权的软件仍需要负责为Realms分配和管理资源,但是,这些高特权软件无法访问Realms的内容或者影响其执行流程。

RME也能动态地将内存转移到Realms的受保护的地址空间。有了RME,给TrustZone软件实体使用的内存可以动态变化。

本文详述了RME引入或改变的关键硬件特性,并向你介绍了软件架构。你将会了解以下概念:

  • 理解RME系统中新的安全状态和物理地址(PA)空间

  • 描述如何在PA空间之间动态分配内存区域

  • 理解启用RME系统的系统需求

本文也解释了RME对处理器架构引入的以下变化:

  • 额外的安全状态

  • 额外的物理地址空间

  • 支持Granule Protection Checks,可以让内存粒度动态分配给物理地址空间

:多元化和包容性对于Arm来说是重要的价值观。因此,我们正在对文档中使用的术语进行重新评估。旧的Arm文档使用了主(master)和从(slave)的术语。本文使用了以下替代术语:

新的术语“Requester”与旧文档中的“master”同义。

新的术语“Subordinate”与旧文档中的“slave”同义。

1.1 学习要求

我们假设你已经熟悉了AArch64异常模型,AArch64内存管理以及TrustZone。如果想了解更多关于这些话题的内容,可以参考以下文:

AArch64异常模型:介绍了在AArch64中的异常和特权模型 AArch64内存管理 :介绍了MMU,它用于控制虚拟到物理地址的转换 AArch64的TrustZone:介绍了TrustZone,这是一种高效的,系统级的安全方法,其特点是在CPU中构建了硬件强制隔离

二、安全状态

RME是基于Arm TrustZone技术构建的。TrustZone在Armv6中被引入,并提供以下两种安全状态:

  • 安全状态

  • 非安全状态

下图显示了AArch64中的两种安全状态,以及通常在每种安全状态下找到的软件组件:

ARMv9的RME安全架构介绍_第1张图片

这种架构将运行在安全状态下的软件与运行在非安全状态下的软件隔离开来。这种隔离使得软件架构能在安全状态下运行受信任的代码,并受到非安全状态下的代码的保护。

RME扩展了这个模型,并提供了以下四种安全状态:

  • 安全状态

  • 非安全状态

  • Realm状态

  • Root状态

下图显示了RME启用的PE中的安全状态,以及这些安全状态如何映射到异常级别:

ARMv9的RME安全架构介绍_第2张图片

保持安全状态为现有的TrustZone使用场景提供了向后兼容性。这些使用场景也可以升级以利用RME新增的功能,如动态内存分配。

Realm状态构建了被称为Realms的受保护的执行环境。重要的是,RME扩展了TrustZone中引入的隔离模型。

架构为以下状态提供隔离:

  • 安全状态  非安全和Realm状态

  • Realm状态  非安全和安全状态

这个隔离模型提供了一种软件架构,在这种架构中,安全状态和Realm状态中的软件是相互不信任的。

使用RME,EL3从安全状态移出,并进入其自己的安全状态,即root状态。RME将EL3从所有其他安全状态中隔离出来。EL3托管平台和初始引导代码,因此必须被非安全状态、安全状态和Realm状态中的软件信任。由于这些安全状态彼此不信任,所以EL3必须处于自己的安全状态中。

2.1 控制当前的安全状态

当前的安全状态由异常级别和SCR_EL3寄存器组合控制。

EL3现在是自己的root安全状态。在EL3中,安全状态始终是root,没有其他异常级别可以处于root状态。

当处于较低的异常级别,如EL0、EL1和EL2时,安全状态由SCR_EL3中的NS和NSE字段控制,如下表所示:

ARMv9的RME安全架构介绍_第3张图片

对于root状态没有编码。在EL3中,当前的安全状态始终是root,无论SCR_EL3.{NSE,NS}的值如何。

在EL3中,SCR_EL3.{NSE,NS}的当前值用于控制一些操作。例如,当在EL3为较低的异常级别发出一个TLB失效指令时,SCR_EL3.{NSE,NS}控制操作应用的安全状态。这是在引入RME之前处理SCR_EL3.NS的同样原理。

2.2 在安全状态之间切换

从TrustZone继承了在安全状态之间切换的原则。要改变安全状态,执行必须通过EL3,如下图所示:

ARMv9的RME安全架构介绍_第4张图片

图中的改变安全状态过程遵循以下步骤:

执行开始在Realm状态,并且SCR_EL3.{NSE,NS}设置为0b11。软件执行一个安全监视器调用(SMC)指令,这导致异常被带入到EL3。

处理器进入EL3,现在处于root状态,因为EL3始终处于root状态。然而,SCR_EL3.{NSE,NS}仍然具有与异常带入的相同的安全状态。EL3中的软件改变SCR_EL3.{NSE,NS}为所需安全状态的相应值,并执行一个异常返回(ERET)。

ERET导致从EL3退出。当离开EL3时,SCR_EL3.{NSE,NS}控制进入哪个安全状态。在这个图中,安全状态是非安全的。

向量寄存器、通用寄存器和大多数系统寄存器只有一份拷贝。当在安全状态之间切换时,保存和恢复寄存器上下文的责任是软件的,而不是硬件的。保存和恢复这个寄存器上下文的软件被称为监视器。

三、物理地址

除了两种安全状态,TrustZone还提供以下两种物理地址空间:

  • 安全物理地址空间

  • 非安全物理地址空间

这些独立的物理地址空间是TrustZone隔离保证的一部分。非安全状态不能访问安全物理地址空间中的地址。这种隔离意味着对属于安全状态的数据有保密性和完整性的保证。

RME扩展了这个保证,以支持以下物理地址空间:

  • 安全物理地址空间

  • 非安全物理地址空间

  • Realm物理地址空间

  • Root物理地址空间

该架构限制了每个安全状态可见的物理地址空间。下表显示了您可以在每个安全状态中访问的物理地址空间:

ARMv9的RME安全架构介绍_第5张图片

在这个表格中,Y表示可以访问,N表示不可访问。

  • SP:0x8000表示安全物理地址空间中的地址0x8000

  • NSP:0x8000表示非安全物理地址空间中的地址0x8000

  • RLP:0x8000表示Realm物理地址空间中的地址0x8000

  • RTP:0x8000表示Root物理地址空间中的地址0x8000

在架构上,每个示例都是一个独立的内存位置。这意味着SP:0x8000和RTP:0x8000被视为不同的物理位置。所有四个位置都可以在RME启用的系统中存在,尽管在实践中,这是不太可能的。

3.1 虚拟地址空间

为了支持新的安全状态,RME为Realm状态引入了以下 Translation Regime:

  • Realm EL1& 0 Translation regime 这种机制包括两个虚拟地址(VA)区域,类似于非安全EL1& 0 Translation Regime。这种 Translation Regime受到第2阶段翻译的影响。

  • RealmEL2&0 Translation regime 这种机制包括两个VA区域,类似于安全EL2&0的 Translation Regime。

  • RealmEL2 Translation regime 这种机制包括一个VA区域,类似于安全EL2的 Translation Regime。

以下图表显示了Realm状态的 Translation Regime:

ARMv9的RME安全架构介绍_第6张图片

对于所有的Realm Translation Regime,任何翻译为非安全物理地址的地址都被视为永不执行。

3.2 Root状态的 Translation Regime

只有EL3存在于Root状态。这意味着有一个单一的 Translation Regime为Root状态,即EL3 Translation regime。这种 Translation Regime在RME之前就存在但先前被认为是安全状态的一部分。

RME对EL3的 Translation Regime进行了以下更改:

  • 虚拟地址可以转换为四个物理地址空间中的任何一个

  • 任何翻译为非安全,安全或Realm物理地址的地址都被视为永不执行

  • MMU table walks只能访问Root PA空间

  • 当在EL3禁用MMU时,所有输出地址都在Root PA空间

注意:EL3继续使用EL3的 Translation Regime,该机制具有一个单一VA范围。

3.3 控制输出PAS

当MMU将虚拟地址转换时,输出PA空间由以下组合控制:

  • 当前的安全状态

  • 当前的异常级别

  • 翻译表

  • 系统寄存器

根据 Translation Regime的不同,软件可用的控制方式也有所不同。现在我们来看看在每个安全状态和 Translation Regime中的控制方式。

3.4 非安全状态 Translation Regime

以下图表显示了非安全 Translation Regime的概览:

ARMv9的RME安全架构介绍_第7张图片

非安全状态只能访问非安全PA空间。因此,在地址翻译的时候,不需要看TTD(Translation Table Describtor)中的NS比特位。

3.5 安全状态 Translation Regime

安全状态可以访问安全和非安全PA空间,如下图所示:

ARMv9的RME安全架构介绍_第8张图片

对于安全EL1& 0 Translation Regime,阶段1翻译表条目中的NS位选择两个中间物理地址(IPA)空间。在EL2,VTCR_EL2和VSTCR_EL2有控制器,将每个IPA空间映射到一个PA空间。

注意:在安全状态下,RME未更改控制方式,本文中的描述是完整的。

3.6 Realm状态 Translation Regime

Realm状态可以访问Realm和非安全PA空间,如下图所示:

ARMv9的RME安全架构介绍_第9张图片

Realm EL0/1 Translation Regime有一个单独的Realm IPA空间。因此,EL0/1阶段一翻译表条目中没有NS位。

Realm阶段二TTDs包括一个NS位,用于映射到Realm或非安全PAS。这意味着,与安全状态不同,Realm状态在阶段二具有每页控制。

Realm EL2 Translation Regime和Realm EL0/2 Translation Regime在阶段一有NS位来控制输出PA空间。

翻译表条目中的NS位由TrustZone引入,允许安全状态选择输出PA空间。在安全状态中,NS位被编码如下:

  • NS=0:安全

  • NS=1:非安全

在RME中,NS字段也用在Realm EL0/1阶段二和Realm EL2/0阶段一翻译表中,但编码为:

  • NS=0:Realm

  • NS=1:非安全

3.7 Root状态 Translation Regime

Root状态可以访问所有PA空间,如下图所示:

ARMv9的RME安全架构介绍_第10张图片

EL3阶段一 Translation Regime在翻译表条目中有两位,NS和NSE,来控制输出PA空间。这些编码类似于用于SCR_EL3.{NSE,NS}的编码,除了有一个编码用于root,如下表所示:

ARMv9的RME安全架构介绍_第11张图片

注意:只有EL1存在于Root状态。EL3只受到阶段一翻译的影响。

3.8 对TLBs和缓存的影响

TLBs缓存最近使用的翻译。TLB条目需要记录条目所属的翻译机制。在TLB查找期间,只有当条目中的翻译机制与请求的翻译机制匹配时,才能返回条目。这防止一个安全状态使用另一个安全状态的TLB条目。

下表显示了一个简化的TLB,记录翻译机制:

ARMv9的RME安全架构介绍_第12张图片

同样,cache line需要记录相关的PA空间,如下图所示:

ARMv9的RME安全架构介绍_第13张图片

四、颗粒保护检查

本节描述了RME引入的颗粒保护检查。颗粒保护检查允许在不同的物理地址空间之间动态分配内存区域。

本节将教你以下特性:

  • 颗粒保护表的结构

  • 颗粒保护检查的故障报告

  • 区域如何在PA空间之间过渡

如在物理地址中所述,RME提供了四个物理地址空间。以下图表显示了这些物理地址空间:

ARMv9的RME安全架构介绍_第14张图片

理论上,每个PA(Physical Address,物理地址)空间都是独立且独立的,并且可以被完全填充。但在实际应用中,大多数设计对DRAM区域只有一个有效的PA空间,通过PA空间划分出各个区域,如下图所示:

ARMv9的RME安全架构介绍_第15张图片

对于片上设备和内存,隔离通常由内存系统执行。这种隔离提供在最终的外设或在互联中。这种配置被称为完整器端过滤,例如:

  • 片上ROM和SRAM,这是仅根访问并由互联强制执行。示例用例包括系统启动。

  • 通用中断控制器(GIC)。所有事务都被路由到GIC,无论PA空间如何。GIC内部使用访问的安全性来控制哪个状态和配置是可访问的。

对于大容量内存,RME提供了一种机制在运行时将页面动态分配给不同的PA空间。例如,启动一个realm时,某些内存的所有权从非安全状态转移到realm状态。当该realm终止时,内存被回收,并且所有权返回到非安全状态。

注意:在系统架构中,被分配的物理地址空间区域被称为资源PA空间。

通过MMU中的Granule Protection Checks(颗粒保护检查)可以 启用将页面动态分配到PA空间。一套颗粒保护表(GPTs)记录了每个位置,该位置为以下两者之一:

  • 完整器端过滤。在此分配中,MMU允许所有访问,并依赖内存系统检查。这些检查可以在互联或外设中进行。

  • 分配给PAS的: -- 在此分配中,MMU只允许输出物理地址空间从VA到PA的翻译与GPTs中的PA空间匹配的访问。 -- 在物理地址空间不匹配的地方,MMU阻止访问并返回颗粒保护错误(GPF)。

从概念上讲,颗粒保护检查是在阶段一和阶段二翻译之后由MMU执行的,如下图所示:

ARMv9的RME安全架构介绍_第16张图片

在这个图示中,阶段显示为串行,但是过程更为复杂。在下面的表格中,我们展示了在NS_EL1中执行的一个LDR指令的例子。为了简化,我们假设阶段1和阶段2都有单独的表级:

ARMv9的RME安全架构介绍_第17张图片

对于正在运行的系统,大多数访问都重用TLBs中的缓存翻译。然而,这个例子强调了翻译的不同阶段和颗粒保护检查之间的互动。在Elision中,我们展示了该过程的一部分可以进行优化。

4.1 颗粒保护表

一套称为颗粒保护表(GPT)的表格,配置了每个颗粒与哪个PA空间关联。当处理器执行访问时,MMU遍历GPT来确定是否允许访问。

颗粒保护检查(GPCs)通过以下系统寄存器进行配置:

  • GPCCR_EL3用于配置:

    o 颗粒保护检查启用

    o 颗粒大小:4K,16K或64K

    o 受保护区域的大小

    o Elision启用

  • GPTBR_EL3用于配置GPT的PA,它位于根PA空间

GPT具有两级表结构,如下图所示:

ARMv9的RME安全架构介绍_第18张图片

GPTBR_EL3指向级别0表的基础。每个级别0的表条目覆盖一个1GB的区域,并且可以是以下格式之一:

  • 块描述符。该块被分配给特定的PAS或配置为允许所有PA空间。

  • 表描述符:

    o 由级别0表条目表示的区域被细分成颗粒,级别1的GPT描述了这些颗粒的映射

    o 描述符给出了级别1表的PA。该表必须位于根PA空间。

Level 1 GPT的每个条目是以下之一:

  • 颗粒描述符

    o 包含16个GPI字段,每个GPI字段描述一个PA空间的颗粒

    o 每个颗粒可以独立地分配给单个PA空间或配置为允许所有PA空间。这种配置将检查访问合法性的责任委托给完整器端过滤器。

  • 连续描述符像颗粒描述符,但描述更大的区域。使用更大的区域可以在TLBs中实现更有效的缓存。

L1表中的每个条目描述16个颗粒,每个颗粒有单独的字段。颗粒大小可以通过GPCCR_EL3进行配置,并匹配用于翻译表的颗粒大小。

因为由级别1表覆盖的地址范围固定为1GB,但颗粒大小可变,所以级别1表中的条目数也会变。选择更小的颗粒大小会导致更大的级别1表。下面的例子显示了使用4KiB和64KiB颗粒大小的级别1表的大小:

ARMv9的RME安全架构介绍_第19张图片

GPTE指的是级别0或级别1 GPT中的一个条目。GPI指的是GPTE中描述内存区域的分配PA空间的字段。

注意:级别0条目的GPI条目只在块描述符中使用。

GPT覆盖的区域从地址0开始,到GPTBR_EL3.PPS定义的上限。GPTBR_EL3.PPS定义的范围之外的任何地址都被视为属于非安全PA空间。

4.2 颗粒保护检查错误

如果访问未通过颗粒保护检查,则报告错误。集合性的,由颗粒保护检查返回的错误被称为颗粒保护检查(GPC)错误。

GPC错误的类型如下:

  • Granule Protection Fault (GPF) GPT行走成功完成,但访问未被允许

  • GPT Walk Fault GPT行走未能完成,原因是GPT条目无效

  • GPT address size fault GPT行走失败,原因是试图访问超出配置范围的地址

  • Synchronous External abort on GPT fetch GPT行走失败,原因是读取GPT条目返回了外部中止

GPC错误作为以下异常类型之一报告:

  • 数据中止异常

  • 指令中止异常

  • GPC异常

GPC异常是RME引入的一种新的同步异常类型。

注意:对跟踪和统计性能扩展(SPE)缓冲区的访问的GPF的处理方式不同。有关更多信息,请参阅Self-hosted trace and SPE。

4.3 颗粒保护错误

当VMSA的VA到PA转换返回的PA空间与GPT中颗粒所分配的PA空间不匹配时,会生成GPF。例如,软件试图访问RLP:0x8000,但PA 0x8000分配给非安全PA空间。GPF可以报告为GPC异常,指令中止异常,或数据中止异常,如下表所示:

ARMv9的RME安全架构介绍_第20张图片

指令中止和数据中止提供的异常综合症已扩展以提供GPF的信息。

GPT行走可能无法完成,并报告以下GPC错误之一:

  • GPT地址大小错误

  • GPT行走错误

  • GPTE获取时的同步外部中止

Arm预期这些错误在系统设置正确的情况下很少出现。这些错误通常代表EL3软件错误或一致性丧失,这可能是致命的。

4.4 通过物理地址空间转移颗粒

通过更新GPT,颗粒在物理地址空间之间移动。架构规范包括软件必须遵循的所需序列。

4.5 对缓存的影响

作为转移块或颗粒的一部分,EL3软件确保在缓存中具有PA空间的位置的副本被删除。

为了删除位置副本,RME引入了物理别名点PoPA),这是缓存层次结构中的一个新的概念点。PoPA是一个点,在这一点之后,使用任何PA空间的访问在缓存或内存中使用相同的副本。下图显示了PoPA的一个例子:

ARMv9的RME安全架构介绍_第21张图片

作为转换流程的一部分,软件清理并使缓存无效到PoPA。这确保在缓存中没有保留旧PA空间的颗粒副本。

注意:并非所有系统都包含超过PoPA的缓存。

4.6 对TLB的影响

TLB存储了最近使用的翻译的副本,可以包括颗粒保护检查的结果。当颗粒在PA空间之间移动时,软件必须发出使无效操作以删除GPTE信息的任何缓存副本。RME为此目的引入了新的TLBI指令。

Arm架构并未指定TLB的结构,且结构可能在实现之间变化。可能的方法包括以下内容之一或组合:

  • 分别缓存不同阶段的结果

  • 将多个阶段的结果作为单个条目进行缓存

软件不需要知道实现了哪种方法。

4.7 省略

在颗粒保护检查中,我们看到了一个示例序列,显示了表行走期间的颗粒保护检查。为了最小化额外检查的性能损失,RME支持一种模式,在该模式中,某些检查被省略。

当省略启用时(GPCCR_EL3.GPCP == 1),MMU可能不会对阶段2表描述符的读取执行颗粒保护检查。所有其他访问,包括阶段1描述符提取和阶段2块和页描述符的提取,都像正常那样进行。

分析省略是否可以接受安全模型包括以下内容的组合:

  • 内存加密的使用和风格

  • 密文是有效转换表描述符的概率低

  • 对读敏感位置的物理地址空间检查的正确实现

五、调试、跟踪和分析

现代Arm系统包括广泛的功能以支持调试和分析。我们必须确保这些功能不能用来破坏系统的安全性。Arm架构,与RME一起,提供了控制以限制哪些系统部分可以进行调试。

本节假设熟悉Armv9-A中的基础功能,并总结了RME引入的更改。

5.1 外部调试

外部调试是指由处理器外部的代理调试软件的情况。下面的图表显示了一个调试探头连接到开发板以及运行调试器的主机机器的示例:

ARMv9的RME安全架构介绍_第22张图片

启用不同的调试、跟踪和分析功能的信号有助于处理此示例中的情况。以下是在不同安全状态下启用调试的单独信号:

  • DBGEN:顶级侵入式调试启用

  • SPIDEN:安全侵入式调试启用,控制外部在安全状态下进行调试的能力

  • RLPIDEN:领域侵入式调试启用,控制外部在领域状态下进行调试的能力

  • RTPIDEN:根侵入式调试启用,控制外部在根状态下进行调试的能力

调试认证信号通常连接到保险丝或认证模块,如下图所示:

ARMv9的RME安全架构介绍_第23张图片

例如,硅供应商在内部使用早期开发硅。这种硅保持了保险丝的完整性,允许调试系统的所有方面。

后来的设备可能会熔断RLIDEN、SPIDEN和RTIDEN的保险丝的组合。这种情况允许开发团队仅对系统的特定区域进行调试。

在出货设备中的最终生产硅中,所有的保险丝都已熔断,以防止任何状态的外部调试。

当外部调试对于某个安全状态被禁用,例如通过熔断保险丝,处理器不能在那个安全状态下进入调试状态。外部调试器仍然可以连接到目标。然而,调试器无法访问目标状态或执行运行控制,直到处理器进入允许外部调试的安全状态。

5.2 自托管调试

自托管调试是指软件由在同一目标上运行的代理进行调试的情况。以下图表显示了在GDB服务器下运行应用程序的示例:

ARMv9的RME安全架构介绍_第24张图片

在这个图中,GDB服务器是运行在目标机器上的调试代理。你可以将一个图形化的调试器连接到服务器。调试器也可以在目标上或在另一台机器上运行,例如,通过SSH连接。

自托管调试的体系结构支持在领域状态下可用。这意味着在领域内操作的VM可以运行一个调试服务器。在这种情况下,控制自托管调试的寄存器是领域上下文的一部分,它们在领域退出时被保存,在领域进入时被恢复。

5.3 自托管跟踪和SPE

RME对Armv9-A中的自托管跟踪支持和SPE进行了最小的修改。在MDCR_EL3中添加了额外的字段,用于控制可以收集跟踪和分析数据的安全状态。

当这些扩展被多个安全状态下的软件使用时,控制这些扩展的寄存器必须由EL3进行上下文切换。自托管跟踪和SPE都使用内存中的软件定义缓冲区来保存分析数据。

对跟踪缓冲区和分析缓冲区的访问受到颗粒保护检查的约束。如果检查失败,故障将通过一个缓冲区管理事件报告,而不是一个异常。这种报告过程与如何处理VMSA阶段1和阶段2故障是一致的。

5.4 性能监控

性能监控扩展(PMU)和活动监控扩展(AMU)并未被RME改变。

当PMU被多个安全状态下的软件使用时,控制这些扩展的寄存器必须进行上下文切换。这是为了避免PMU被用来暴露一个安全状态到另一个安全状态的相关信息。

AMU提供的信息更有限,旨在用于作为电源管理的一部分进行活动监控。Arm建议在调度领域时不要进行CNT_CYCLES和CPU_CYCLES的上下文切换或禁用。在AMU提供更多计数器的地方,对计数器的访问由EL3控制。

5.5 分支记录缓冲区扩展

Armv9.2-A分支记录缓冲区扩展(BRBE)并未被RME改变。当BRBE被多个安全状态下的软件使用时,控制BRBE的寄存器必须进行上下文切换。

六、SMMU架构

SMMU架构扩展以支持颗粒保护检查。在本文的这一部分,我们描述了SMMU在RME启用系统中的使用以及对SMMU架构的主要更改。

6.1 在RME启用系统中的SMMU

一个系统包括多个可以独立访问内存的设备,如DMA控制器或GPU。下面的图表显示了一个简化的系统:

ARMv9的RME安全架构介绍_第25张图片

任何可以访问内存的设备,因此是一个请求者,都必须受到TrustZone和RME的物理地址空间隔离保证。

对于依赖于完成者端过滤的区域,这种隔离保证是在内存系统中实现的。请求者指定它想要访问的PA和PAS空间。内存系统或目标外设确定是否允许访问。这个过程与TrustZone没有改变。

RME提供了动态将内存页分配给不同PAS的支持。所有设备对可分配位置的访问必须根据GPT进行检查。对于CPU,这个访问是由MMU处理的。对于其他设备,访问是由SMMU处理的。

下面的图表显示了一个使用SMMU进行颗粒保护检查的示例系统:

ARMv9的RME安全架构介绍_第26张图片

在显示简化示例系统的图中,在RME之前,GPU和DMA使用SMMU进行转换。在启用RME的系统中,SMMU还提供颗粒保护检查。

然而,GIC是一个不会通过SMMU连接的设备的例子。GIC可以访问内存并需要颗粒保护检查。在启用RME的示例系统中,GIC通过SMMU连接,但SMMU只提供颗粒保护检查。

6.2 对RME的SMMU架构的更改

RME对SMMU架构进行了以下更改,以支持更多的安全状态和PA空间:

  • Client devices and SECSID 在SMMU架构中,SECSID标识客户端设备的安全状态。只能识别安全和非安全的客户端设备。不支持Root或Realm客户端设备。

  • Clients devices that do not have a StreamID 在SMMU架构中,StreamID用于识别发送事务的客户端设备,并确定要执行什么转换。 RME扩展了SMMU架构,以支持没有StreamID的事务。这些事务受到颗粒保护检查,但不受阶段1或阶段2的转换。Arm预计这种支持将用于像在RME启用的系统中的SMMU中的示例系统中的GIC这样的设备。也就是说,这种支持用于那些通常不会连接到SMMU但需要颗粒保护检查的设备。

  • SMMU-originated accesses 来自SMMU的访问,例如读取流表,受到颗粒保护检查。这些检查与PE MMU的阶段1或阶段2步行的访问一样,都受到颗粒保护检查。 当一个来自SMMU的访问触发了一个颗粒保护检查的故障时,它被报告为SMMU经历了一个外部中止。

七、系统架构

RME不仅仅是一组处理器功能。为了利用RME引入的功能,我们需要在系统的其余部分得到支持。

下面的图表显示了一个示例系统以及RME引入后受影响的组件:

ARMv9的RME安全架构介绍_第27张图片

7.1 主内存保护

启用RME的系统包括内存加密和可能的完整性。基线加密要求支持外部内存的加密,每个PA空间使用单独的加密键或调整。这种加密还提供了使用地址调整的空间隔离。

本文将提供外部内存加密和完整性服务的组件称为内存保护引擎(MPE)。

7.2 MPAM

在RME之前,内存分区和监控扩展(MPAM)为非安全状态和安全状态定义了独立的PARTID空间,这些状态由MPAM_NS值区分。MPAM_NS在非安全和安全的资源使用监视器之间进行选择。每个监视器可以对PARTID或PARTID和PMG,或仅PMG敏感。MPAM_NS传递的PARTID空间用于选择哪个监视器银行跟踪资源使用。

由于主机资源管理的考虑,可能需要在非安全状态和realm安全状态之间共享PARTID空间。在某些情况下,共享PARTID空间可能会泄露工作负载行为的信息。例如,使用非安全监视器监控realm访问是一个潜在的侧通道。将缓存分区分配给一个realm是可能用于缓存计时攻击的一种机制。

使用RME,MPAM_NS被一个2位的MPAM_SP取代。这个MPAM空间字段允许系统实现四个独立的PARTID空间,每个安全状态一个。MPAM_SP也定义了如何多个安全状态可以共享一个PARTID空间。安全状态允许系统集成商决定如何在Arm CCA系统中实现MPAM。这个实现决定基于每个MPAM内存系统组件(MSC)所暴露的风险。

7.3 RAS

对于启用RME的系统,RAS支持的关键需求是要保持RME提供的安全隔离边界,即保密性和完整性。这个需求的挑战在于,你可能希望在非安全状态下,由hypervisor或内核代码对RAS进行分级处理。这意味着在非安全状态下运行的PEs可以直接访问经过清理的错误记录寄存器。

RME引入了机密信息的概念,这种信息在正常操作下对当前安全状态来说是不可访问的。例如,非安全状态通常无法访问安全或realm内存位置的内容。

RME对RAS可以公开的信息进行了限制:

  • Root状态可以查看属于任何安全状态的信息

  • 安全状态可以查看属于安全或非安全状态的机密信息,但不能查看root或realm的信息

  • Realm状态可以查看属于realm或非安全状态的机密信息,但不能查看root或安全状态的信息

  • 非安全状态不能查看属于任何其他状态的机密信息

并非所有与错误相关的信息都被视为机密。通常,可以报告资源的地址和严重性。例如,可以向非安全状态报告发生在realm位置的RAS故障。故障记录可以报告错误类型,以及遭受故障的位置的地址。然而,它不允许公开关于该内存位置内容的任何信息。

 

你可能感兴趣的:(ARM,ARM,v9,RME,ARM安全架构)