为何ARM部分指令支持CMODX安全，其他指令却不支持？

一、为何指定指令具备CMODX安全性？ #

这些被标记为CMODX安全的指令核心特性是执行逻辑简单、行为边界绝对明确，不会产生介于原指令与修改后指令之间的中间状态：

• 均为单32位指令字（ARM32/ARM64下存储为原子操作），不存在跨指令字的依赖或组合逻辑；
• 执行结果仅有两种明确可能：要么完全符合原指令的行为，要么完全符合修改后指令的行为。比如分支指令（B、B.cond、BL等）仅会执行跳转或不跳转的动作，异常触发指令（SVC、HVC、SMC）仅会触发对应类型的异常，NOP、ISB等指令的行为本身就是固定的空操作或同步动作，没有模糊的中间执行状态。

二、其他指令会引发何种问题？ #

非CMODX安全指令的执行通常涉及复杂逻辑，并发修改时会触发不可预测的严重行为：

• 算术/逻辑类指令：这类指令涉及寄存器读写、运算操作，若执行过程中指令被修改，可能出现原指令操作码搭配修改后操作数的情况，导致计算结果完全偏离预期，甚至破坏寄存器状态；
• 内存访问类指令：并发修改可能导致指令访问错误的内存地址，触发未定义的内存读写行为，进而破坏数据完整性；
• 架构层面允许此类指令并发修改时表现为同一异常级下的任意指令序列行为，即可能出现完全不符合原指令或修改后指令的执行流程，引发程序崩溃、数据损坏等问题。

三、流水线为何会观测到既非原也非修改后的不一致指令？ #

尽管32位指令字的存储是原子操作，但CPU流水线的多阶段异步处理机制会导致这种情况：

• 前端取指通常以16/32/64字节的窗口批量加载指令到预取缓冲区，若在预取完成后、指令被分割解码前，内存中的目标指令被原子修改，预取缓冲区仍保留原指令的字节内容，后续解码/执行阶段可能错误地将原指令片段与修改后的指令片段组合（尤其在ARM32支持Thumb 16位指令的场景下，指令边界判断容易出错）；
• 流水线的取指、解码、执行阶段是重叠进行的：当某条指令处于解码阶段时内存中的该指令被修改，执行阶段可能基于未完成的解码结果（原指令的部分逻辑）和修改后的指令内容混合处理，最终产生既非原指令也非修改后指令的异常行为；
• 架构规范明确允许这种不一致行为存在，因此非安全指令必须通过显式同步（如内存屏障）来避免并发修改与执行的冲突。

内容的提问来源于stack exchange，提问作者Changbin Du