前置知识

AArch64 异常模型

https://developer.arm.com/documentation/102412/latest

Privilege and Exception levels特权和异常级别

Exception level -> EL

有四种异常级别：EL0、EL1、EL2 和 EL3。

The architecture does not specify what software uses which Exception level. A common usage model is application code running at EL0, with a rich Operating System (OS) such as Linux running at EL1. EL2 may be used by a hypervisor, with EL3 used by firmware and security gateway code. For example, Linux can call firmware functions at EL3, using software interface standards, to abstract the intent from the lower-level details for powering on or off a core. This model means the bulk of PE processing typically occurs at EL0/1.

Processing Element -> PE

the Exception level can only change when any of the following occur:
仅当发生以下任一情况时，异常级别才会更改：

Taking an exception 例外
Returning from an exception 从异常中返回
Processor reset 处理器重置
During Debug state 调试状态下
Exiting from Debug state 退出调试状态

There are two types of privilege relevant to the AArch64 Exception model:
有两种与 AArch64 异常模型相关的权限：
Privilege in the memory system
内存系统中的特权
Privilege from the point of view of accessing processor resources
从访问处理器资源的角度来看的特权
Both types of privilege are affected by the current privileged Exception level.
两种类型的特权都受到当前特权异常级别的影响。

Memory privilege 内存特权
Arm 架构的 A-profile 实现了虚拟内存系统，其中内存管理单元 (MMU) 允许软件为内存区域分配属性。这些属性包括读/写权限，可以将其配置为允许特权访问和非特权访问的单独访问权限。

In the Arm architecture, registers are split into two main categories:
在 Arm 架构中，寄存器分为两大类：
Registers that provide system control or status reporting
提供系统控制或状态报告的寄存器
Registers that are used in instruction processing, for example to accumulate a result, and in handling exceptions
用于指令处理（例如累积结果）以及处理异常的寄存器

System Control Register (SCTLR)
There is a System Control Register (SCTLR) for each implemented Exception level. Each register controls the architectural features for that EL, such as the MMU, caches and alignment checking:
每个实现的异常级别都有一个系统控制寄存器（SCTLR）。每个寄存器控制该 EL 的架构特性，例如 MMU、缓存和对齐检查：
SCTLR_EL1
Top-level system control for EL0 and EL1
SCTLR_EL2
Top-level system control for EL2
SCTLR_EL3
Top-level system control for EL3

Execution and Security states执行和安全状态

The AArch64 architecture provides four Exception levels.There are also two Execution states and up to four Security states.The current state of an Armv8-A or Armv9-A processor is determined by the Exception level and the current Execution state.
AArch64 架构提供了四个异常级别。还有两个执行状态和最多四个安全状态。 Armv8-A 或 Armv9-A 处理器的当前状态由异常级别和当前执行状态决定。

Execution states 执行状态
Armv8-A 和 Armv9-A 支持两种执行状态：AArch32,AArch64
Armv8-A：灵活支持 AArch32 和 AArch64，复位时的执行状态由实现决定。
Armv9-A：强制要求 AArch64，在复位时执行状态必须是 AArch64，但在用户态（EL0）可以选择支持 AArch32。

Security states 安全状态

Secure state 安全状态
In this state, a Processing Element (PE) can access both the Secure and Non-secure physical address spaces, and the Secure copy of banked registers.
在此状态下，处理元件 (PE) 可以访问安全和非安全物理地址空间以及存储寄存器的安全副本。
Non-secure state 非安全状态
This is often also referred to as Normal world. In this state, a PE can only access the Non-secure physical address space. The PE can only access System registers that allow non-secure accesses.
这通常也称为正常世界。在这种状态下，PE只能访问非安全物理地址空间。 PE 只能访问允许非安全访问的系统寄存器。

Armv8-A：EL3 始终在 Secure state 中，用于管理安全和非安全世界之间的转换。
Armv9-A：默认情况下 EL3 仍然在 Secure state 中，但如果实现了 RME，EL3 会成为 Root state 的一部分，与 Secure state 的其他部分分离，提供更高级别的安全隔离和管理。

At EL0, EL1, and EL2 the PE can be in either Secure state or Non-secure state. You often see this written as: 在 EL0、EL1 和 EL2，PE 可以处于安全状态或非安全状态。你经常看到这样写：
NS_EL1: Non-secure state, Exception level 1
NS_EL1：非安全状态，异常级别 1
S_EL1: Secure state, Exception level 1
S_EL1：安全状态，异常级别 1

Realm Management Extension(RME)领域管理扩展
Armv9-A introduced support for the Realm Management Extension (RME). When RME is implemented, two additional Security states are supported:
Armv9-A 引入了对领域管理扩展 (RME) 的支持。实施 RME 时，支持两种附加安全状态：
Realm state: In this state a PE can access Non-secure and Realm physical address spaces.
Realm状态：在此状态下PE可以访问非安全和Realm物理地址空间。
Root state: In this state a PE can access all physical address spaces. Root state is only available in EL3.
根状态：在此状态下PE可以访问所有物理地址空间。根状态仅在 EL3 中可用。

补充：RME
https://developer.arm.com/documentation/den0126/latest/

补充：trustzone
https://developer.arm.com/documentation/102418/latest/

补充：虚拟化 https://developer.arm.com/documentation/102142/latest/

Exception types异常类型

The Arm architecture categorizes exceptions into two broad types: synchronous exceptions and asynchronous exceptions.
Arm架构将异常分为两大类：同步异常和异步异常。

Synchronous exceptions 同步异常

There are many different types of synchronous exception, and it is possible that a given instruction might cause multiple synchronous exceptions. The Arm architecture provides a fixed priority order for synchronous exceptions. 同步异常有许多不同类型，并且给定指令可能会导致多个同步异常。 Arm 架构为同步异常提供固定的优先级顺序。

同步异常的一些不同原因：

1. Invalid instructions and trap exceptions 无效指令和陷阱异常 例如，EL1 处的操作系统内核可能会禁用 EL0 处浮点指令的使用，以节省应用程序之间上下文切换的时间。惰性上下文切换（lazy context-switching）

2. Memory accesses 内存访问
   这可能是由于 MMU 执行的检查或内存系统返回的错误造成的。
   补充：内存也可能引起异步异常
   https://developer.arm.com/documentation/101811/latest/

3. Exception-generating instructions 异常生成指令
   Arm 架构包括异常生成指令 SVC、HVC 和 SMC。这些指令的目的仅仅是生成异常并使 PE 能够在异常级别之间移动：
   Supervisor Call (SVC) 指令使 EL0 处的用户程序能够请求 EL1 处的 OS 服务
   Hypervisor Call (HVC) 指令（如果实施了虚拟化扩展，则可用）使 OS 能够请求 EL2 处的虚拟机管理程序服务
   Secure Monitor Call (SMC) 指令（如果实施了安全扩展，则可用）使普通世界能够从 EL3 处的固件请求安全世界服务

服务调用路由：

在虚拟化环境中，虚拟机监控程序可以通过设置 HCR_EL2.TSC 位，将客户操作系统的 SMC 指令陷阱到 EL2 层级进行处理，从而有效控制和仿真系统行为。这种机制确保了虚拟机监控程序对客户操作系统的全面控制，同时提供了灵活的系统管理能力。

4. Debug exceptions 调试异常
   Debug exceptions are synchronous exceptions that are routed to the Exception level where a debugger is hosted. The debugger code then executes much like exception handler code.
   调试异常是路由到托管调试器的异常级别的同步异常。然后，调试器代码的执行方式与异常处理程序代码非常相似。

补充：self-hosted debug 自托管调试
https://developer.arm.com/documentation/102120/latest/

In AArch64, synchronous aborts cause a synchronous exception. Asynchronous aborts cause an SError interrupt exception.
在 AArch64 中，同步中止会导致同步异常。异步中止会导致 SError 中断异常。

Asynchronous exceptions 异步异常

1. Physical interrupts 物理中断:

• SError 错误
  System Error
  补充：通用中断控制器 v3 和 v4
  https://developer.arm.com/documentation/198123/latest/

• IRQ and FIQ IRQ 和 FIQ

在 ARM 架构中，IRQ（Interrupt Request） 和 FIQ（Fast Interrupt Request） 是两种不同类型的中断机制，用于处理不同优先级的中断请求。
在 AArch64 架构中，FIQ（Fast Interrupt Request）和 IRQ（Interrupt Request）的优先级相同，都是异步中断，并且它们的处理方式没有像在某些早期架构中那样显著不同。相较于旧的 ARM 架构（如 AArch32），FIQ 通常具有比 IRQ 更高的优先级，但在 AArch64 中，这种优先级的差异已经被消除。两者的优先级可以通过软件配置，而不是硬件固定。
所有 Arm 实现都使用 Arm 通用中断控制器 Generic Interrupt Controller (GIC) 架构来管理 IRQ 和 FIQ。

2. Virtual interrupts 虚拟中断:

• vSError, Virtual System Error
• vSError，虚拟系统错误
• vIRQ, Virtual IRQ vIRQ，虚拟IRQ
• vFIQ, Virtual FIQ vFIQ，虚拟 FIQ

Masking 掩蔽
ARM 架构中的异步异常（如中断）可以被暂时屏蔽，保持挂起状态，直到解除屏蔽后再处理。而同步异常（如指令执行错误）无法屏蔽，因为它们会直接阻止指令执行。2021 年引入的 Armv8.8-A 和 Armv9.3-A 扩展增加了不可屏蔽中断（NMI）的支持，允许某些中断在被屏蔽情况下仍能处理，确保关键任务的及时响应。

Handling exceptions处理异常

在 ARM 架构中，当处理器元素 (PE) 响应异常时，会进行异常处理。异常处理分为两个状态：异常来源状态（异常处理前的状态）和异常目标状态（异常处理后的状态）。例如，处理器可以从 AArch32 EL0 状态下进入异常处理，切换到 AArch64 EL1 状态。

处理完成后，系统需要返回到异常处理前的状态，这称为异常返回。ARM 架构提供了触发异常返回的指令。异常返回同样涉及两个状态：异常返回来源状态（异常返回指令执行前的状态）和异常返回目标状态（异常返回指令执行后的状态）。

When an exception occurs, the processor saves the current status of the PE alongside the exception return address, and then enters a specific mode to handle the exception.
当异常发生时，处理器将PE的当前状态与异常返回地址一起保存，然后进入特定模式来处理异常。

当处理器遇到异常时，会保存处理单元（PE）的当前状态和异常返回地址，然后进入一个特定模式来处理异常。以下是发生异常时的一般流程：

1. 保存当前处理器状态：

当前处理器状态（PSTATE）的快照会被保存到 Saved Program Status Register (SPSR)。
异常返回地址会被保存到 Exception Link Register (ELR)。
对于同步异常和SErrors，异常原因会记录在 Exception Syndrome Register (ESR)。

2. 进入特定异常级别：

当异常被带到使用AArch64状态的异常级别（ELx）时：
异常发生前的PSTATE内容被写入到 SPSR_ELx。
优先的异常返回地址被写入到 ELR_ELx。
此外，对于同步异常和SError中断，异常原因信息会写入到 ESR_ELx。
对于地址相关的同步异常（如MMU错误），触发异常的虚拟地址会写入到 Fault Address Register (FAR_ELx)。

3. 异常向量表：

异常处理从一个固定的内存地址开始，该地址称为异常向量。异常发生时，处理单元会跳转到向量表中的一个位置进行处理。

在 AArch64 架构中，异常向量表与许多其他处理器架构不同，它包含的是指令而不是地址。每个向量表条目包含最多 32 条指令，这些指令通常足够执行基本的寄存器保存操作（stacking）并调用特定的异常处理代码。

AArch32 到 AArch64 寄存器映射：
AArch32 -> AArch64
R0-R12 -> X0-X12
Banked SP and LR -> X13-23
Banked FIQ -> X24-30

AArch64 has a concept of processor state known as PSTATE, it is this information that is stored in the SPSR. PSTATE contains things like current Exception level and Arithmetical Logical Unit (ALU) flags. In AArch64, this includes:
AArch64 有一个称为 PSTATE 的处理器状态概念，正是该信息存储在 SPSR 中。 PSTATE 包含当前异常级别和算术逻辑单元 (ALU) 标志等内容。在 AArch64 中，这包括：

Condition flags 条件标志
Execution state controls 执行状态控制
Exception mask bits 异常掩码位
Access control bits 访问控制位
Timing control bits 时序控制位
Speculation control bits 推测控制位

For example, the following Exception mask bits (DAIF) in PSTATE allow exception events to be masked. The exception is not taken when the associated bit is set.
例如，PSTATE 中的以下异常屏蔽位 (DAIF) 允许屏蔽异常事件。当相关位被置位时，不会发生异常。
D - Debug exception mask bit 调试异常屏蔽位
A - SError asynchronous exception mask bit, for example, asynchronous external abort 异步异常屏蔽位，例如异步外部中止
I - IRQ asynchronous exception mask bit 异步异常屏蔽位
F - FIQ asynchronous exception mask bit 异步异常屏蔽位

PE自动保存异常返回地址和当前PSTATE,PSTATE 作为快照存储在 SPSR（已保存程序状态寄存器）中,每个异常级别都有一个 SPSR，SPSR_ELx。
然后，PE 将当前 PSTATE 更新为架构中为该异常类型定义的 PSTATE，反映新状态。这包括更新受影响的目标异常级别和安全级别。

异常的目标要么由体系结构固定，要么由软件使用路由控制进行配置（一定不是EL0）。
同步异常（Synchronous Exceptions）根据与产生异常的指令（例如 SVC、HVC 和 SMC）相关的规则进行路由。对于这些指令，它们的异常处理会根据指令本身的类型被路由到适当的异常级别（EL）。例如：
SVC（Supervisor Call）：通常用于从用户模式请求内核服务，异常会被路由到 EL1。
HVC（Hypervisor Call）：用于与虚拟化相关的调用，异常会被路由到 EL2。
SMC（Secure Monitor Call）：用于调用安全监视器，异常会被路由到 EL3。
对于实现的其他异常类型，如异步异常（包括 IRQ、FIQ 和 SErrors），它们可以独立配置路由到 EL2（Hypervisor）或 EL3（Secure Monitor）。

When taking an exception to an Exception level using AArch64, vector tables are an area of normal memory containing instructions that are then used to handle the exception.
当使用 AArch64 将异常处理为异常级别时，向量表是普通内存的一个区域，其中包含用于处理异常的指令。
每个异常级别都有自己的向量表，其基地址由其自己的向量基地址寄存器 VBAR_EL 定义。

在 AArch64 中，架构允许选择两个堆栈指针寄存器：SP_EL0 或 SP_EL，其中 是当前的异常级别（EL）。例如，在 EL1 时，可以选择 SP_EL0 或 SP_EL1。当发生异常时，处理器会自动选择目标异常级别的堆栈指针 SP_ELx，根据以下规则进行配置：
如果在 EL0 执行，处理器使用 SP_EL0。
如果在 EL1、EL2 或 EL3 执行，处理器使用由 PSTATE.SP 位确定的堆栈指针：
如果 PSTATE.SP 为 0，则使用 SP_EL0。
如果 PSTATE.SP 为 1，则使用当前异常级别的堆栈指针 SP_ELx。

从异常中返回：
Restoring all previously stacked corruptible registers 恢复所有先前堆叠的损坏寄存器
Initiating an exception return instruction (ERET) 启动异常返回指令（ ERET ）

虚拟化

https://developer.arm.com/documentation/102142/latest/

Hypervisors can be divided into two broad categories: standalone, or Type 1, hypervisors and hosted, or Type 2, hypervisors.
虚拟机管理程序可分为两大类：独立虚拟机管理程序（或类型 1）和托管虚拟机管理程序（或类型 2）。

The two most commonly used open-source hypervisors on Arm platforms are Xen (standalone, Type 1) and KVM (hosted, Type 2).
Arm 平台上最常用的两种开源虚拟机管理程序是 Xen（独立，类型 1）和 KVM（托管，类型 2）

Software running at EL2 or higher has access to several controls for virtualization:
在 EL2 或更高版本上运行的软件可以访问多个虚拟化控件：
Stage 2 translation 第二阶段翻译
EL1/0 instruction and register access trapping
EL1/0指令和寄存器访问捕获
Virtual exception generation
虚拟异常生成

这张图展示了虚拟地址空间（Virtual Address Space）、操作系统认为的物理地址空间（What the OS thinks is the Physical Address Space）以及真实的物理地址空间（Physical Address Space）之间的关系，并通过两级地址转换表（Stage 1 和 Stage 2 Tables）来实现不同层级的地址映射。

虚拟地址空间：
包括应用程序、内核和外设等部分。应用程序和内核都运行在虚拟地址空间中，通过一级转换表（Stage 1 Tables）将虚拟地址映射到操作系统认为的物理地址空间。

操作系统认为的物理地址空间：
这是操作系统在第一级地址转换后认为的物理地址空间，通常包括DDR、外设和闪存。在这个阶段，地址转换主要是为了操作系统和应用程序的虚拟内存管理。

真实的物理地址空间：
包括DDR、外设、闪存、SRAM和ROM。这是真实存在的硬件资源的位置。

地址转换：
Stage 1 Tables：负责将虚拟地址空间转换为操作系统认为的物理地址空间。
Stage 2 Tables：进一步将操作系统认为的物理地址空间转换为真实的物理地址空间。这种两级转换机制在虚拟化环境中特别有用，可以有效地隔离和管理虚拟机访问物理硬件资源的权限。

（没看完）

安全

https://developer.arm.com/documentation/102406/latest/

Confidentiality 保密性
Integrity 完整性
Authenticity 真实性
Availability 可用性
（Availability is about ensuring that, even if attacked, the user can still access and use an asset. 可用性是指确保即使受到攻击，用户仍然可以访问和使用资产。）

Vulnerability: An underlying bug or weakness in a system
漏洞：系统中潜在的错误或弱点
Exploit: A specific attack that exploits a vulnerability
漏洞利用：利用漏洞的特定攻击
Attacker: Also called an adversary, someone trying to compromise an asset
攻击者：也称为对手，试图破坏资产的人
Threat: A combination of an attacker, an exploit, and one or more assets that are being attacked
威胁：攻击者、漏洞利用以及受到攻击的一个或多个资产的组合

Different security features in the Arm architecture
Arm 架构中的不同安全功能

笔记

The following diagram shows a complete view of how Realms fit within an Arm CCA system:

Realm VM 的执行通过传递给 Monitor 的 hypervisor 命令进行初始化，然后通过 Monitor 推送到 RMM。

物理地址空间pas：

颗粒保护检查：

Attestation is broken into two key parts:
• Attestation of the platform平台认证
• Attestation of the initial state of the RealmRealm初始状态的证明

在每个世界中，异常级别 2 执行可以通过执行 SMC 指令来调用异常级别 3 监视器。

Realm 管理接口 （RMI） 是 RMM 和 Normal 世界主机之间的接口。

Realm 服务接口 （RSI） 是 Realm VM 和 RMM 之间的接口。