Arm Cortex-M programmer model

1、前言

Armv8-M架构参考手册给Arm Cortex-M CPU定义了一组规则，只有符合这里面的所有规则，才可以说CPU是兼容ARM架构的，因此，Arm还专门开发了ACK工具，用于检查自己或客户的CPU产品是否符合架构规则。

Armv8-M programmer model主要包含如下，下文将分别阐述，不过FP、MVE和Exception内容较多，后续单开文章讲它们。

2、PE states

不像Armv8-A架构用于A32、A64和T32三种指令集，Armv8-M只支持T32指令集。它定义的PE使用模型有：

Thread模式：应用程序。复位时选择该模式，而且PC会加载reset handler起始地址。

Handler模式：操作系统内核和相关功能，用于管理系统资源。PE只在该模式下处理exceptions。

在Handler模式下，PE使用main stack (MSP)，在Thread模式下，CONTROL.SPSEL决定PE是使用process stack (PSP)还是main stack (MSP)。在exception进入和退出时，PE会自动更新CONTROL.SPSEL。

Thread模式下可以继续细分PE是否是privileged或unprivileged（是通过CONTROL.nPRIV来决定Thread模式的privilege，当然只有privileged写才能修改nPRIV的值），Handler模式总是privileged，无法改写。Privilege可以确定一个资源是否允许访问，而且通常privileged执行比unprivileged执行可以访问更多的资源。

3、TrustZone

如果PE实现了Security Extension，也就是支持TrustZone，那么会有Secure和Non-secure两种模式，那么标记为Secure的memory区域和其它关键资源只能被处于Secure状态的PE访问。

PE的Security状态切换是通过Branch跳转到处于不同Security状态的地址来进行的。如下图所示。

Secure内存中的SG指令是Secure代码的有效入口点，它可以防止Non-secure代码跳转到Secure代码中的任意地址。当PE处于Secure状态时，任何尝试执行任何位于Non-secure内存的指令都会导致INVTRAN SecureFault产生。

因此，除了SG指令，在Non-secure状态下执行Secure代码是不可能的。在Secure状态下也不可能执行Non-secure代码。

在memory访问中，NS-Req指示PE或DAP请求执行memory访问时所处的Security状态。NS-Attr将memory访问标记为Secure或Non-secure。对于PE data accesses，NS-Req等于当前的Security状态。对于PE和DAP访问，NS-Attr的取值如下：

CPU刚上来时，马上会去找VTOR来取vector table的内容。Vector table包含了以下两部分：

复位时main stack的指针初始值；

每个exception handler的起始地址；

Exception number定义了这些exception的handler入口的顺序：

Vector fetch可以使用instruction interface来执行，并避免匹配到DWT和watchpoints。

在具有security extension的PE中，会实现了两个vector table，分别是secure vector table和non-secure vector table。这两个vector table放置的基地址是IMPLEMENTATION DEFINED是否可配置的。

PE支持每个vector table基地址是可配置的，那么会有两个vector table offset registers：VTOR_S和VTOR_NS；

PE不支持任意一个向量表基地址是可配置的，那么VTOR_S和VTOR_NS是WI属性；

如果PE支持每个vector table基地址可配置：

针对secure状态的exception使用VTOR_S来确定secure vector table的基地址；

针对non-secure状态的exception使用VTOR_NS来确定non-secure vector table的基地址；

如果PE没有支持security extension，那么只有一个VTOS寄存器。

4、寄存器

Armv8-M支持以下类型的寄存器：

GPR寄存器的R13也是Stack pointer，R14也是Link Register，R15也是Program Counter。Mask Registers主要用于修改exception的优先级。Control寄存器用于控制PE的一些feature是否打开或切换。SP limit register主要是保护堆栈，防止溢出。XPSR存放程序执行的状态。VPR和FPSCR用于FP或MVE下，控制predication和feature，以及提供程序状态。

Arm architecture需要Context synchronization event(CSE, 上下文同步事件)来保证对architecture中描述的任何memory-mapped registers的任何修改的可见性。当发生CSE事件时，在CSE事件之后的指令可以看到CSE之前已经完成的对memory-mapped registers的写操作（不管之后的指令是想direct read还是indirect read，都是可以看见的）。

以下这些事件会产生CSE：

执行ISB操作。在执行ISB指令且通过condition code检查；

处理exception，包括tail-chaining；

从exception返回；

进入Debug状态；

退出Debug状态；

通过interstating branches和返回的security状态转换不是CSE事件。

5、Lockup

Lockup是一种PE状态，这种状态出现的场景是：当PE停止执行指令来响应错误时，但由于当前的execution priority无法将错误升级到恰当的HardFault handler。比如，在处理secure HardFault过程中，又出现了synchronous exception要升级为secure HardFault的场景，但此时由于secure fault已经active了，因此无法升级为secure HardFault了，这时就发生lockup了。

Arm建议在实现中提供一个LOCKUP信号，当PE处于lockup状态时，向外部系统发出PE处于lockup的信号。

当PE处于lockup时：

读取DHCSR.S_LOCKUP的值为1；

读取PC的值为0xEFFFFFFE，这是一个XN地址；

PE停止取值和执行指令了；

如果实现有LOCKUP信号，那么LOCKUP信号会置起来；

Asynchronous busfault不会导致lockup。

退出lockup只能通过以下几种方式之一：

Cold reset

Warm reset

进入debug状态

通过NMI exception来抢占

不过Arm认为进入lockup状态是一种致命的情况了，建议直接reset了。

6、Coprocessor和CDE

Coprocessor

Arm architecture支持0-16个协处理器，CP0到CP15。如果CDE不使用CP0到CP7，则CP0到CP7是IMPLEMENTATION DEFINED的。CP0到CP7是否可以在secure和non-secure状态下使用，或者协处理器是否只能在secure和non-secure状态下启用，这是由IMPLEMENTATION定义的。

Arm预留了CP8到CP15，CP10到CP11被保留以支持Floating-point Extension，CP10控制CP11浮点指令。

发给未实现或禁用的协处理器的指令会导致NOCP UsageFault。如果协处理器不能完成一条指令，则生成UNDEFINSTR UsageFault。

Custom Datapath Extension (CDE)

CDE在协处理器指令空间中引入了两条指令的三种类型：

三种类型对GPR寄存器进行操作，包括condition code标记APSR_nzcv

三种类型仅对floating-point或SIMD寄存器进行操作

在floating-point或SIMD寄存器上操作的Custom Datapath instruction使用以下方法之一：

32-bit S 寄存器；

64-bit D寄存器

128-bit Q寄存器

CDE指令的三种类型由以下模式定义：

<operation code> <destination register>.

<operation code> <destination register>, <source register>.

<operation code> <destination register>, <source register 1>, <source register 2>.

Custom Datapath instruction的目的寄存器可选读取，也可选写入。

Custom Datapath instructions可以在现有的协处理器编码和编号空间中找到，并与之关联。Custom Datapath instructions属于与协处理器编号相关的编码空间，范围从0到7。

启用实现了Custom Datapath Extension的协处理器空间与其它IMPLEMENTATION DEFINED协处理器相同，都是使用IsCPEnabled()。

如果协处理器与Custom Datapath Extension相关联，那么该协处理器不能执行以下指令，因为它们是coprocessor的指令。

CDP, CDP2.

LDC, LDC2 (immediate).

LDC, LDC2 (literal).

MCR, MCR2.

MCRR, MCRR2.

MRC, MRC2.

MRRC, MRRC2.

STC, STC2.

当执行CDE指令时，PE检查与CDE相关的协处理器是否启用。如果需要访问另一个协处理器，例如floating-point extension或MVE，则执行第二次协处理器检查。

CDE指令如下：

VCX1, VCX1 (vector).

VCX2, VCX2 (vector).

VCX3 , VCX3 (vector).

7、PACBTI

PAC和BTI特性可以针对每个security状态和privilege级别独立启用或禁用。

PAC

Pointer Authentication Code。由加密算法生成的哈希值。PAC也指用于生成哈希的过程。对于pointer authentication，有四个128-bit keys，如下图：

在下列情况下，特权软件可以通过MSR和MRS指令访问密钥：

将寄存器值PAC_KEY_P_3: PAC_KEY_P_2: PAC_KEY_P_1: PAC_KEY_P_0连接成PAC_KEY_P。

将寄存器值PAC_KEY_U_3: PAC_KEY_U_2: PAC_KEY_U_1: PAC_KEY_U_0连接成PAC_KEY_U。

对于pointer authentication指令，是否使用以下方法生成加密值是IMPLEMENTATION DEFINED：

QARMA5

IMPLEMENTATION DEFINED algorithm

QARMA3

Arm建议应该使用QARMA系列算法进行pointer authentication。

PAC由PACBTI、PAC和PACG指令生成。

如果PAC authentication指令验证PAC失败，则会生成INVSTATE UsageFault。如果在验证PAC之前，用于产生PAC的任何输入参数（三个通用寄存器的任何一个或加密密钥）被修改，那么会产生fault。指令AUT、BXAUT和AUTG用于验证PAC。

加密算法的输出是32位PAC，因此输入参数和加密密钥的不同组合可能产生相同的PAC。PAC authenticatio指令无法检测到这种类型的加密冲突，并且不会生成INVSTATE UsageFault。

有了PAC之后，在有Branch发生时，刚进入Branch，PE会将LR+硬件密钥+SP一起算出一个合法签名PAC放到R12中，R12和LR会一起压到栈中。在Branch返回时，会将R12和LR一起返回校验。由于其他人无法知道密钥，因此R12的值是不可能被篡改的，这样就保护了LR值。这是一套硬件、编译器以及架构强制绑定的流程。

BTI

Branch Target Identification。用于创建和识别有效分支branch landing pads的机制。它用于保护跳转的地址是正确的。EPSR.B在exception entry时会自动stack和清0，并在exception return中恢复。

当BTI启用时，则任何指令可以设置EPSR.B或LO_BRANCH_INFO.BTI为1的称为BTI setting指令。比如BLX、BLXNS、BX、BXNS、LDR_PC等。

任何指令可以设置EPSR.B为0的称为BTI clearing指令。BTI, SG, PACBTI是BTI clearing指令。如果EPSR.B为1，BIT clearing指令将会把它清0，甚至BTI没有enable也会。

当EPSR.B为1，则下一条执行的指令必须是BTI clearing指令或BKPT指令，否则会产生INVSTATE UsageFault。如果下一条指令是BTI clearing指令，那么EPSR.B会被清0。但如果下一条是BKPT指令，EPSR.B不会被清0，而且会保持原来的值且不会产生INVSTATE UsageFault。