ARMv8-AArch64 的非常处理模型详解之非常品级、执行状态以及安全状态 ...

一，特权和非常品级

在了解AArch64非常品级模型之前，有必要先明白特权的概念。当代软件被开辟成不同的模块，每个模块对体系和处理器资源有不同的访问级别。比如操作体系内核和用户应用程序的划分。操作体系内核必要高级别的权限来访问体系资源，然而应用程序应当被限制其设置体系的能力。即特权规定了软件实体可以看到和控制哪些处理器资源。
AArch64架构通过实现不同级别的特权来实现这种拆分。当前特权级别只能在处理器发生非常或从非常返回时进行更改。因此，这些特权级别在Arm体系结构中被称为非常级别。
1.1 非常品级 Exception levels

AArch64使用 EL 来命名非常品级，EL3权限最高，EL0权限最低。如下图所示，为一种通用的非常品级模型：

• 用户应用程序执行在EL0。
  
• 操作体系，比如Linux执行在EL1.
  
• Hypervisor， 比如虚拟机程序，执行在EL2
  
• 固件或者安全网关相干代码，执行在EL3.
  比如，在EL1的Linux可以使用软件接口标准在EL3上调用固件函数。这个模型意味着大部分的PE处理通常发生在EL0/1处。
  
  
  
  非常品级何时会发生改变，只有如下几种环境：
  
• 发生非常：Taking an exception，产生非常能让非常品级增长或者保持稳固，但绝不大概通过产生非常进入到一个更低品级的非常。
  
• 从一个非常返回：Returning from an exception。从一个非常返回能让非常品级降低或者保持稳固，但绝不大概通过非常品级返回进入到一个更高品级的非常。
  
• 处理器发生reset：Processor reset
  
• 处于调试状态：During Debug state
  
• 离开调试状态：Exiting from Debug state
  

二，特权的范例

有两种与AArch64非常模型相干的特权范例：

• 内存体系的特权
  
• 来自访问处理器资源的视角的特权
  这两个特权范例都受到当前非常品级的影响。
  

2.1 内存特权

ARM架构的A处理器系列实现了一个虚拟内存体系：内存管理单位，Memory Management Unit (MMU)，MMU允许软件对不同的内存区域分配不同的内存属性。这些属性包罗读/写权限，可以设置为允许对特权访问和非特权访问的单独访问权限。
当处理器在EL0中执行时启动的内存访问将根据无特权的访问权限进行检查。来自EL1、EL2和EL3的内存访问将按照特权访问权限进行检查。
由于这种内存设置是由软件使用MMU的translation tables来控制的，以是我们应该思量编辑这些table时的特权品级。由于MMU的设置是存储在处理器体系寄存器里的，而控制访问这些寄存器的权限也来自于当前的非常品级。
   在ARM架构中，处理器的寄存器主要分成两大类：
  

• 提供体系控制（system control）和状态表现（status reporting）的寄存器
  
• 用于指令处理的寄存器，比如结果累计以及非常处理。
  

  2.2 访问寄存器的特权

AArch64处理器的设置被保存在一系列的体系寄存器当中，体系控制寄存器中的各种设置的组合决定了当前处理器的上下文（context）。并且，访问体系寄存器的权限也由当前处理器的非常品级决定。
ARM架构里有许多概念上有相似功能的寄存器，它们仅仅是非常品级后缀名不同，比如AArch 64中的VBAR（Vector Base Address Register）寄存器存在VBAR_EL1，VBAR_EL2以及VBAR_EL3，这些寄存器是相互独立的存在，在指令会合有不同的解码，以及在硬件中独立的实现。这些寄存器名字相同是由于他们的功能相似，但是它们是完全独立的寄存器，具有它们自己的访问语义。体系寄存器名称的后缀表现可以从中访问该寄存器的最低非常级别。
比如AArch64处理器中的体系控制寄存器，System Control Register (SCTLR)，为每个非常品级都实现了一个SCTLR。每个寄存器控制着当前非常品级的一些架构级别的特性，比如MMU，cache以及对齐访问检查功能等：

• SCTLR_EL1 ：对EL0 和 EL1 最高级的控制寄存器
  
• SCTLR_EL2：对EL2 最高级的控制寄存器
  
• SCTLR_EL3：对EL3 最高级的控制寄存器
  为什么没有SCTLR_EL0寄存器？由于EL1和EL0共用相同的MMU设置和体系，并且控制权限掌控在EL1中，所有的控制均来自EL1中可访问的寄存器。
  别的，高非常品级可以访问低非常品级的寄存器。比如当处理器处于EL2时，它可以去访问SCTLR_EL1。当时当处于EL0时，SCTLR_EL1将不可被访问，如果试图去访问的话，体系将会进入非常。
  在一般环境下，处理器处于什么非常品级，就访问该品级的相干寄存器，但也存在访问低级别寄存器的环境，比如用于实现虚拟化特性或者处理器上下文切换等等。
  

RegisterNameDescriptionException Link RegisterELR_ELx非常链接寄存器，保存着导致非常发生的那条指令的所在Exception Syndrome RegisterESR_ELx非常综合寄存器，保存着非常发生的原因相干的信息Fault Address RegisterFAR_ELx错误所在寄存器，保存着非常发生时的非常错误所在Secure Configuration RegisterSCR_ELx安全设置寄存器， 控制着安全状态，以及进入EL3的非常Hypervisor Configuration RegisterHCR_ELx控制着虚拟化设置，以及进入EL2的相干非常System Control RegisterSCTLR_ELx体系控制寄存器，控制着标准内存，体系设置，以及为已实现的相干功能提供状态信息。Saved Program Status RegisterSPSR_ELx当非常发生，并切换到ELx时，保存着处理器的相干状态Vector Base Address RegisterVBAR_ELx当非常发生时，处于ELx，保存着ELx的非常向量表的基址 三，执行状态和安全状态

上文提到过，AArch64 架构支持4种非常品级，除了非常品级，它还支持两种执行状态（AArch32和AArch64)，以及两种安全状态（secure和non-secure）。 以是对于Armv8-A 或者Armv9-A的处理器，它们的当前状态，取决于当前的执行状态以及非常品级。
3.1 执行状态 Execution states

当前的执行状态，不但决定了处理器的通用寄存器（general-purpose register）的位宽：AArch32状态下是32 bit，AArch64状态下是64 bit的宽度。还决定了当前处理器所使用的指令集（instruction sets）：AArch32状态下使用A32指令集，AArch64状态下使用A64指令集。
从Armv8-A 开始，支持以下两种执行状态：

• AArch32：AArch32是32-bit的执行状态，在AArch32状态下的操作是向后兼容之前的架构（ARMv7）的，以是它支持T32以及A32指令集。处理器当位于AArch32状态时，其标准寄存器都是32 bit的宽度。
  
• AArch64 ：AArch32是32-bit的执行状态，它支持A64指令集，并且处理器当位于AArch64状态时，其标准寄存器都是64 bit的宽度。
  

3.2 执行状态切换

如果想改变处理器的执行状态，只有以下两种方式：

• Colde Reset或者Warm reset。
  
• 非常品级切换
  

当处理器进行非常品级切换的时间，有大概改变当前的执行状态，但是无论怎么在AArch32和AArch64直接切换，都必须要遵守如下规则：

• 当非常品级从一个低品级切换到更高品级的时间，执行状态可以保持稳固，或者切换到AArch64。
  
• 当非常品级从一个高品级切换到更低品级的时间，执行状态可以保持稳固，或者切换到AArch32。
  

把这两个规则放在一起，意味着64-bit 可以承载 32-bit，但是反之不可。比如，64-bit的操作体系内核支持64-bit应用和32-bit应用，但是32bit的操作体系却只能跑32-bit应用。如下图所示：

在这个例子中，我们使用了操作体系和应用程序作为示例，其实这个规则对所有非常品级都实用。比如，当EL2是一个32-bit的hypervisor时，EL1只能是一个32-bit的操作体系。同理，当最高非常品级（EL3）为AArch32 状态时，当前处理器肯定不支持通过非常处理切换，进入到AArch64，由于当前已经是最高非常品级（EL3），无法通过切到更高的非常品级进入AArch64。
在Armv8-A架构中，所有的非常品级都支持AArch32和AArch64，这是根据详细的架构实现界说的功能，对于每个非常品级，可以选择都支持，或者只支持其中一个。别的ARMv8 处理器的默认执行状态（即reset之后的执行状态）是详细的实现界说的，比如Cortex-A32在reset之后都是AArch32 状态。
在Armv9-A架构中，AArch64是强制要求所有非常品级实现的状态，并且只有EL0才支持AArch32（实现界说），其他非常品级都是处于AArch64下。当发生reset时，处理器的执行状态将始终是AArch64。
3.3 安全状态 Security states

大部分Cortex-A系列处理器都支持两种安全状态：

• 安全状态，Secure state：在安全状态下，一个处理器单位（Processing Element）可以访问secure和non-secure下的物理所在空间，以及secure的bank 寄存器。
  
• 非安全状态，Non-secure：非安全状态也被称为Normal world，在这种状态下，PE只能访问Non-secure的物理所在空间，并且访问体系寄存器也是non-secure的访问。
  

比如在Android 体系，一般跑在Normal world（non-secure）下，当时当支付时，或者运行DRM （数字版权管理，Digital Right Management，DRM）体系时，将会切到Secure状态下。我们必要对安全世界体系有更高水平的信托，并必要将它们分开，以保护诸如支付细节和密钥等信息，Secure和non-secure两种安全状态可以提供这种分离。下图时非常品级和Secure状态之间的组合：

3.4 改变安全状态

如果处理器实现了TrustZone，那么便可以通过 SCR_EL3的NS bit来选择 Secure 状态照旧Non-Secure状态。EL3状态拥有最高特权的非常品级，并且EL3的的安全状态是固定的，当处于EL3时，它能访问所有的bank 寄存器。Armv8-A的 EL3 总是处于安全状态（Secure state)，在Armv9-A中，EL3是安全状态的一部分，除非实现了RME。如果实现了RME，则Root state是EL3与安全状态的其他部分的分离。
无论何时，要从一种安全状态切换到另一种安全状态，都必须通过EL3。EL3上的软件负责管理对不同可用安全状态的访问，控制着EL2，EL1以及EL0的安全状态。怎样改变安全状态呢：

• 改变SCR_EL3.NS的值
  
• 然后从EL3返回（ERET）
  

四，非常品级和执行状态的详细实现分析

是否将所有的非常品级的都实现，这是有详细的架构实现界说的，并且可以界说每个非常品级的所支持的执行状态。
其中EL1和EL0是必须要实现的，而EL3和EL2是可选的。
如果EL2或EL3没有实现，那必须思量以下：

• EL2包含大量的虚拟化功能，如果没有实现EL2，将不能使用这些虚拟化特性。
  
• 由于只有EL3才可以改变安全状态，以是如果没有实现EL3，处理器将只有一种安全状态，并且不能改变，由详细的实现决定。
  我们使用的一些软件也依靠于这些非常品级，比如虚拟机体系就必要至少实现EL2、EL1和EL0。
  

在ARMv8.0 A中，EL2只支持Non-secure状态，这是由于Secure 状态下不支持虚拟化扩展。从ARMv8.4-A开始，增长了 S.EL2作为一个可选的属性，并附带一个使能 bit ： SCR_EL3.EEL2，以提供向后的兼容性。在Armv9-A中，如果实现了EL2，那么必须要支持两种安全状态（secure和non-secure），并且也提供了一个disable bit。
Armv8-A系列的处理器可以为每个非常品级选择哪些执行状态有效，并且这也是详细的实现界说的。如果AArch32被运行执行在某个非常品级，那么也必须可以执行在比当前更低的非常品级。比如EL3可以跑AArch32，那么EL2，EL1以及EL0肯定都可以跑。
很多处理器的详细实现会把所有的安全状态以及所有的非常品级都打开，但是仍存在着一些限制，比如：

• Cortex-A35 支持AArch32和AArch64在所有的非常品级
  
• Cortex-A32 只支持 AArch32.
  
• Neoverse-N2只支持AArch32跑在EL0，其他非常品级只能跑AArch64.
  

AArch32提供对老的32-bit 架构（比如ARMv7）的向后兼容性，但是从ARMv9开始，AArch32被限制在只能跑在EL0，并且还只是可选的实现，同时全方便支持AArch64（所有非常品级都支持）。这意味着ARMv9固然支持32-bit，但是也只限于一些应用程序，像操作体系内核、hypervisor，虚拟化程序以及firmware固件都接纳64-bit。
   参考链接： Learn the architecture - AArch64 Exception
Model

免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！更多信息从访问主页：qidao123.com:ToB企服之家，中国第一个企服评测及商务社交产业平台。