Skip to content
STIMSMITH

ARM Architecture

Concept WIKI v4 · 8/11/2026

ARM Architecture is treated in the evidence primarily as a weakly consistent instruction-set platform studied in systems-security and binary-analysis research. The supplied evidence covers ARM in four principal contexts: (1) as a target ISA for differential testing of instruction decoders (Fleece), where ARMv8 has comparatively few but real decoding errors; (2) as a hardware-security-feature substrate for in-process compartmentalization using Pointer Authentication (PA) and Memory Tagging Extension (MTE) (Capacity); (3) as an evaluation architecture for post-quantum cryptography benchmarking (PQC-LEO); and (4) as a weakly consistent multiprocessor architecture whose programmer-visible concurrency behaviour requires more elaborate semantics than simple state-update or store-buffer models, motivating integrated ISA-plus-concurrency-model specifications (the Sail/POWER/ARM line of work).

Overview

Across the supplied evidence, ARM Architecture is positioned primarily as a weakly consistent instruction-set platform that is studied, evaluated, and exploited in systems-security and binary-analysis research. The evidence treats ARM in four principal contexts:

  • As a weakly consistent multiprocessor ISA whose programmer-visible concurrency behaviour cannot be expressed as a simple per-instruction state-update model, motivating the development of integrated ISA-plus-concurrency-model specification frameworks such as Sail.
  • As an ISA used as a differential-testing target for instruction decoders (Fleece), where ARMv8 instruction encoding is examined alongside x86-64 and PowerPC.
  • As a modern hardware platform whose newer security features (Pointer Authentication, Memory Tagging Extension) substitute for x86's Protection Keys for Userspace (PKU) and can be retrofitted into a capability-based in-process access control scheme (Capacity).
  • As a principal evaluation architecture in a post-quantum cryptography benchmarking framework (PQC-LEO), where performance scaling differs from x86.

ARM as a weakly consistent multiprocessor (Sail / POWER-and-ARM concurrency work)

The Sail/POWER paper places ARM alongside IBM POWER as a canonical weakly consistent multiprocessor whose programmer-visible behaviour cannot be captured by a per-instruction state-update model. The paper argues that:

  • "For a single-threaded processor one can regard instructions simply as updating a global register and memory state. The same holds for a sequentially consistent (SC) multiprocessor, and TSO multiprocessor behaviour (as in x86 and Sparc) requires only the addition of per-thread store buffers. But for weakly consistent multiprocessors such as IBM POWER and ARM, and of the non-multi-copy atomic storage subsystem, some aspects of out-of-order and speculative execution, are exposed to the programmer; we cannot use a simple state-update model for instructions." [C1, C2]
  • Weak consistency makes traditional ARM and POWER architecture documentation inadequate: "This is especially problematic for the concurrency behaviour of weakly consistent multiprocessors such as ARM and IBM POWER, where programmer-visible microarchitectural optimisations expose many subtleties: the traditional documentation does not define precisely which programmer-observable behaviour is (and is not) allowed for concurrent code." [C2]
  • The paper introduces Sail as a new instruction description language that "permits instruction descriptions to be expressed in [a] familiar imperative style while simultaneously supporting the structure we need for integration with the concurrency model." [C1, C2]
  • The argument presented is that an "architectural envelope specification," precisely defining the range of allowed behaviour for arbitrary code, should be mathematically rigorous, executable as a test oracle, executable as an emulator, and readable by practising engineers. ARM is identified as one of the key motivations for this approach, alongside POWER. [C2]

Although the Sail paper's worked example is POWER, the framework is introduced explicitly as applicable to ARM-class weakly consistent multiprocessors, and ARM is named as a primary motivator throughout the discussion of why a simple per-instruction semantics is insufficient. [C1, C2]

Instruction-decoder testing: ARM as an ISA target in Fleece

The Fleece paper studies binary instruction decoders by generating test inputs and using differential testing with reassembly to identify decoding errors. The supplied evidence places ARMv8 among the ISAs tested. The paper reports quantitative results for ARM that contrast with x86 and PowerPC.

  • In Table II ("Testing results from applying Fleece to several decoders"), ARM is reported with 6,051 inputs, 4,337 differences, and a testing time of 3 minutes 9 seconds, compared to 482,711 inputs for x86 in 508 minutes and 3,629 inputs for PowerPC in 1 minute 2 seconds. The paper notes that "x86 testing generated about 100x as many inputs as ARM and PowerPC testing." [C1, C2]
  • In Table IV ("Comparison of testing results using random inputs and Fleece-generated inputs"), Fleece on ARM discovers 4,337 unique differences in 3:09 from 6,051 inputs, while random inputs on ARM process 1,706,422 inputs in 10 minutes and produce only 600 unique differences. The paper's accompanying text states that "for each architecture, Fleece discovers more unique differences in less time," and that "for both ARM and PowerPC, the difference between Fleece and the random input generation is less dramatic, yet it persists because instructions with 15 bits devoted to the opcode or reserved are still fairly rare in random inputs (1 in 32768), but are frequently generated by Fleece." [C1, C2]
  • Table III ("Number of errors reported for each tool") records that "x86 decoders had far more errors on average than other decoders, while ARM decoders tended to have the fewest errors." The per-decoder ARM error counts are: XED n/a, libopcodes 2, LLVM 1, Dyninst 7, Capstone 3. [C3]

The paper's ARM-specific findings:

  • "ARMv8 decoders had the fewest errors, but each decoder had at least one." [C3]
  • "LLVM was the most reliable [ARM] decoder, which is not surprising, because it receives commits from ARM employees and is recommended as the authoritative ARM decoder." [C3]
  • "The most common error in ARM decoding is the example provided for LLVM in Table I, a load instruction used for transaction-based computation. LLVM decodes this instruction as invalid because unused operands have values other than the typical compiler-generated values (all 1s) for this instruction." [C3]
  • "Compared to the errors identified in x86-64 decoders, the errors we discovered in ARM decoders are more related to aliasing and correctly identifying valid instructions and less related to operands and addressing modes, likely because ARM instructions have distinct forms of each opcode that describe the types of operands used." [C3]
  • ARM-specific example errors in Table I include: libopcodes producing mov w8, w26 instead of orr w8, wzr, w26, lsr #4; LLVM decoding a valid ldaxrb w24, [sp] as invalid; Dyninst producing eor q9, q5, q0 with general-purpose register naming instead of the vector form eor v9.16b, v5.16b, v0.16b; and Capstone failing to recognize a valid instruction, instead reporting invalid for bytes that should decode to mov v10.h[7], v11.h[2]. [C4]
  • The paper also describes a version-dependent difference for ARMv8: "libopcodes version 2.26 supports ARMv8.1, so it decoded 727 instructions that are only valid in ARMv8.1, while the other decoders viewed these as invalid inputs," illustrating how ARM's revision history affects decoder behavior. [C4]
  • A worked example in Fig. 6 of the paper shows a single ARM instruction 0x630844e0 decoded differently by libopcodes, Capstone, Dyninst, and LLVM, with libopcodes and LLVM producing valid equivalent decodings (mov v0.d[0], v7.d[1] and ins v0.d[0], v7.d[1] respectively, both reassembling to the same bytes), while Capstone reports invalid and Dyninst produces an erroneous decoding (ins Q0, Q7) that fails reassembly. [C5]

The paper additionally notes ARM's instruction-set evolution as a source of complexity:

  • "Likewise, both ARM and PowerPC have undergone significant revisions since their creation. Each revision or extension requires an updated decoder. Additionally, extensions can produce new interactions between opcodes and operands that might affect existing instructions." [C6]

Hardware-assisted in-process access control on ARM (Capacity)

The Capacity paper positions ARM's recent security features as the architectural analog of x86's PKU for in-process compartmentalization.

  • "Unfortunately, the modern ARM architecture does not have an equivalent feature [to PKU]. Instead, newer ARM architectures introduced Pointer Authentication (PA) and Memory Tagging Extension (MTE), adapting the reference validation model for memory safety and runtime exploit mitigation." [C7]
  • Capacity "coherently incorporates the new hardware security features on ARM that already exhibit inherent characteristics of capability," and "with intra-process domains authenticated with unique PA keys, Capacity transforms file descriptors and memory pointers into cryptographically-authenticated references and completely mediates reference usage with its program instrumentation framework and an efficient system call monitor." [C7]
  • The prototype is evaluated on NGINX with reported overheads of "approximately 17% for the single-threaded and 13.54% for the multi-threaded webserver." [C7]

Post-quantum cryptography on ARM (PQC-LEO)

  • The PQC-LEO framework "is designed to automate the evaluation of PQC computational and networking performance across x86 and ARM architectures." [C8]
  • Its proof-of-concept evaluation "shows that there is a greater performance reduction in implementing PQC methods with higher security on ARM architectures than on the x86 architecture." [C8]

Scope of this article

The evidence covers ARM as a weakly consistent multiprocessor whose concurrency semantics motivate Sail-style integrated specifications; as a tested ISA in decoder differential testing; as a hardware-security feature platform used for in-process capability systems; and as a benchmarking target for post-quantum cryptography.

CITATIONS

10 sources
10 citations
[1] ARM is grouped with IBM POWER as a weakly consistent multiprocessor that cannot be modelled with a simple per-instruction state-update semantics; TSO architectures (x86, Sparc) require only per-thread store buffers, while ARM and POWER expose additional out-of-order and speculative behaviour to the programmer. An integrated concurrency and core-ISA architectural envelope definition, and test oracle, for IBM POWER multiprocessors
[2] The Sail paper names ARM alongside POWER as a key motivation for executable, mathematically rigorous architectural envelope specifications, arguing that traditional ARM/POWER documentation is inadequate to define allowed concurrent behaviour, serve as a test oracle, or act as an emulator. An integrated concurrency and core-ISA architectural envelope definition, and test oracle, for IBM POWER multiprocessors
[3] Fleece Table II reports ARMv8 testing with 6,051 inputs, 4,337 differences, and a runtime of 3:09, compared with 482,711 inputs in 508 minutes for x86 and 3,629 inputs in 1:02 for PowerPC, with the paper noting that x86 testing generated about 100x as many inputs as ARM and PowerPC testing. Structured Random Differential Testing of Instruction Decoders
[4] Fleece Table IV reports that on ARM, Fleece-generated inputs yield 4,337 unique differences from 6,051 inputs in 3:09, whereas random inputs process 1,706,422 ARM inputs in 10 minutes yielding only 600 unique differences, attributed to the rarity (1 in 32768) of opcodes with 15-bit opcode or reserved fields in random input. Structured Random Differential Testing of Instruction Decoders
[5] Fleece Table III records per-decoder error counts on ARMv8: XED n/a, libopcodes 2, LLVM 1, Dyninst 7, Capstone 3, with ARMv8 decoders having the fewest errors among tested architectures. Structured Random Differential Testing of Instruction Decoders
[6] ARM-specific Table I example errors in Fleece: libopcodes producing `mov w8, w26` instead of `orr w8, wzr, w26, lsr #4`; LLVM reporting valid `ldaxrb w24, [sp]` as invalid; Dyninst producing `eor q9, q5, q0` rather than vector-form `eor v9.16b, v5.16b, v0.16b`; Capstone reporting invalid for bytes decoding to `mov v10.h[7], v11.h[2]`. Structured Random Differential Testing of Instruction Decoders
[7] Fig. 6 of the Fleece paper shows a single ARM instruction (bytes `0x630844e0`) decoded differently across libopcodes, Capstone, Dyninst, and LLVM: libopcodes and LLVM produce valid decodings that reassemble to the input bytes, Capstone reports invalid, and Dyninst produces an erroneous decoding that fails reassembly. Structured Random Differential Testing of Instruction Decoders
[8] The Fleece paper notes that both ARM and PowerPC have undergone significant revisions, each requiring decoder updates, and that extensions can produce new opcode-operand interactions affecting existing instructions. Structured Random Differential Testing of Instruction Decoders
[9] The Capacity paper states that modern ARM lacks a PKU-equivalent feature, and instead newer ARM architectures introduced Pointer Authentication (PA) and Memory Tagging Extension (MTE), which Capacity uses together with PA-key-authenticated intra-process domains to implement capability-based in-process compartmentalization. Capacity
[10] The PQC-LEO framework automates evaluation of PQC computational and networking performance across x86 and ARM, with the proof-of-concept showing greater performance reduction for higher-security PQC methods on ARM than on x86. PQC-LEO

VERSION HISTORY

v4 · 8/11/2026 · minimax/minimax-m3 (current)
v3 · 7/30/2026 · minimax/minimax-m3
v2 · 7/12/2026 · minimax/minimax-m3
v1 · 7/3/2026 · gpt-5.5