ARMv8.3-A history + Apple

ARMv8.3-A history + Apple implementation

ARMv8.3-A was announced in 2016 as an enhancement to the 64-bit ARMv8-A architecture. It built on ARMv8.2 with mandatory* and optional features aimed at improving performance, security, and virtualization.

* Mandatory features are the architectural extensions that every ARMv8.3-A core must implement-most notably Pointer Authentication and the RCpc memory‐model enhancements-whereas optional features are those that silicon vendors (users? vendors? difference?) may choose to include, such as nested virtualization, JavaScript conversion instructions, 52-bit virtual addressing, and extended cache size registers.

Notably, ARMv8.3 made Pointer Authentication (PA or PAuth) a mandatory feature of the ISA, introduced hardware support for nested virtualization, and added new instructions (e.g. for memory ordering and JavaScript conversion) to extend the architecture’s capabilities. These extensions evolved in subsequent ARM revisions (v8.4, v8.5, etc.), but ARMv8.3 marked a key turning point in hardware security for general-purpose CPUs.

Apple’s adoption

Apple began implementing ARMv8.3-A features in its System on Chips (SoCs) soon after its introduction.

* A SoC is a single custom-designed integrated circuit that combines ARM CPU cores (both high-performance “Firestorm/Icestorm” or “Avalanche/Blizzard” in M-series), a GPU, Neural Engine, image signal processor, unified memory controllers, Secure Enclave, and various I/O and accelerators to maximize performance-per-watt and enable tight hardware-software integration across iPhone, iPad, and Mac platforms.

The Apple A12 Bionic (2018, used in iPhone XS/XR) was one of the first Apple chips to support the ARMv8.3-A Pointer Authentication extension. Then, Apple’s A-series and M-series designs incorporated and expanded on ARMv8.3 features. This laid the groundwork for Apple’s transition to Apple Silicon Macs: by the time the M1 chip (2020) arrived, Apple’s CPUs supported PA and related security features.

Apple’s M1 corresponds roughly to an ARMv8.5-A level implementation, which means it includes all ARMv8.3 features and some later ones (like Branch Target Identification from v8.5). Subsequent M2/M3 generations adopted improvements (e.g., the ARMv8.4 nested virtualization optimizations) while maintaining backward compatibility with ARMv8.3-A instructions. (I am not entirely sure how backward compatibility works here; this is more of something I have picked up on while reading).

Apple’s usage of ARMv8.3-A in macOS aligns with its strategy of tight hardware-software co-design. The switch from Intel x86_64 to ARM64e (Apple’s Pointer Authentication-enabled 64-bit ABI) was not just a power/performance move, but also a security upgrade… inheriting advanced hardware defenses long used in iOS.

Now, let’s look around on our mac Terminal.app

1. Query CPU feature flags with sysctl

macOS exposes each optional (and mandatory) A-core feature under hw.optional.arm.FEAT_*. On an M1/M1 Pro/M2/M3, you’ll see the ARMv8.3-A bits flipped on:

# Pointer Authentication (mandatory in v8.3-A)
sysctl -n hw.optional.arm.FEAT_PAuth
# → 1

# RCpc memory-model enhancements (v8.3-A mandatory)
sysctl -n hw.optional.arm.FEAT_LRCPC
# → 1
sysctl -n hw.optional.arm.FEAT_LRCPC2
# → 1

# JavaScript-conversion instructions (v8.3-A optional)
sysctl -n hw.optional.arm.FEAT_JSCVT
# → 1

If you run a full dump:

sysctl -a | grep hw.optional.arm.FEAT

you’ll see a long list including FEAT_PAuth, FEAT_LRCPC, FEAT_JSCVT, and a handful of later extensions (e.g., FEAT_PAuth2, FEAT_FPAC remain 0 until you hit ARMv8.6-A on newer silicon).

On my mac, for example, all of those return 1 (i.e. “present”):

image