PACMAN Under the Hood: How Speculative Execution Shattered Apple Silicon’s Hardware Pointer Authentication (PAC)

In contemporary microprocessor architecture, software memory corruption vulnerabilities—such as buffer overflows, format string bugs, and use-after-free exploits—have long been the dominant weapon of cyber attackers. To eliminate these vulnerabilities at the hardware level, Arm introduced Pointer Authentication (PAC) in the Armv8.3-A specification, subsequently integrated across millions of modern Apple Silicon processors (A12 through A18 and M1 through M4). By cryptographically signing memory pointers using high-speed hardware cryptographic primitives, PAC was hailed as the ultimate, impassable silicon shield against control-flow hijacking.

The security paradigm of Pointer Authentication rested on a seemingly unassailable mathematical assumption: an attacker attempting to forge a 16-bit cryptographic PAC signature must guess blindly. Because an incorrect signature immediately triggers a non-maskable hardware exception that terminates the process, brute-forcing the key would crash the application or induce an immediate kernel panic within milliseconds.

That fortress was completely demolished by MIT CSAIL researchers with PACMAN. By weaponizing speculative execution inside the transient execution window of out-of-order CPU cores, PACMAN converts hardware pointer authentication into a silent microarchitectural side-channel oracle. An attacker can brute-force the cryptographic PAC key across all 65,536 combinations in under three minutes without triggering a single hardware crash or kernel panic. Here is the exhaustive, microarchitectural disassembly of how PACMAN executes, why hardware cryptographic authentication fails under transient speculation, and the architectural aftermath for modern silicon security.

1. The Cryptographic Fortress: How Armv8.3 Pointer Authentication (PAC) Operates

To understand why PACMAN was such a catastrophic shock to computer architecture, one must examine how Pointer Authentication is structured. In standard 64-bit microprocessors (such as modern ARM64 and x86-64), virtual memory addressing does not utilize all 64 bits of an address pointer. Operating systems typically configure address spaces to 48 bits (supporting 256 Terabytes of virtual memory) or 52 bits.

Consequently, the upper 12 to 16 bits of every 64-bit pointer are completely unused:

Armv8.3-A and Apple Silicon weaponize these unused high bits by embedding a Pointer Authentication Code (PAC). When a function prepares to write a return address or function pointer to the stack:

1. The compiler emits a PAC signing instruction, such as PACIASP (Pointer Authentication Code for Instruction pointer, using Key A and Stack Pointer modifier).
2. The processor passes three inputs into an internal, hardware-accelerated tweakable block cipher known as QARMA:
   • The 64-bit virtual memory address to be protected.
   • A 64-bit contextual modifier (typically the current Stack Pointer SP or an object address).
   • An internal 128-bit secret processor key (e.g., APIAKey or APDAKey) stored in privileged CPU registers inaccessible to user software.
3. The QARMA engine produces a truncated 16-bit cryptographic Message Authentication Code (MAC). The CPU inserts this 16-bit MAC directly into the high unused bits of the pointer.

Before the program executes a return instruction or calls the function pointer, the compiler emits an authenticating instruction: AUTIASP (Authenticate Instruction pointer). The CPU recomputes the QARMA MAC using the same inputs. If the computed MAC matches the bits embedded in the pointer, the CPU strips the PAC high bits, restoring a valid 48-bit address.

However, if an attacker has exploited a heap corruption bug to overwrite the pointer with an invalid forged address, the MAC check fails. Crucially, the architectural specification dictates that the CPU intentionally corrupts the address by flipping two upper address bits to invalid values. When the subsequent return instruction (RET or BLR) attempts to execute the corrupted address, the Memory Management Unit (MMU) catches a translation fault and immediately issues a SIGSEGV / kernel panic, killing the exploit in its tracks.

2. The Mathematical Security Assumption: Why Brute Force Should Fail

Because the PAC field is constrained by the virtual address width, the signature length is typically limited to 16 bits (yielding \(2^{16} = 65,536\) possible combinations).

In classical cryptography, a 16-bit key is trivial to brute-force on modern computers in less than a second. But in Pointer Authentication, brute-force was considered mathematically impossible due to the Immediate Crash Guarantee:

If an attacker attempts to guess the PAC signature, their very first guess has a 99.998% chance of being wrong. An incorrect guess immediately triggers a fatal kernel panic or terminates the target daemon. Even if the daemon auto-restarts, macOS and iOS security daemons re-seed their secret 128-bit PAC keys upon initialization, completely randomizing the target signature and rendering multi-attempt brute-forcing completely futile.

3. The PACMAN Mechanism: Speculative Execution as a Verification Oracle

The core discovery of PACMAN is that while architectural PAC execution crashes the processor on failure, transient speculative execution suppresses hardware exceptions entirely.

Modern high-performance processors (especially Apple Silicon cores with their massive 630-entry Reorder Buffers) execute dozens of instructions out-of-order down anticipated branch paths while waiting for slow memory operations to resolve. If the branch predictor turns out to have guessed wrong, the hardware flushes all transient architectural registers back to their previous state as if the instructions never happened.

Crucially, transient execution exceptions are never architecturally reported. If a speculatively executed instruction triggers an invalid memory dereference or MMU translation fault, the CPU suppresses the exception, waiting to see if the branch actually commits. If the branch was mispredicted, the fault is silently discarded without crashing the process!

The PACMAN attack constructs a specialized speculative gadget inside the target application or kernel:

The attacker executes this sequence:

1. The branch predictor is trained by calling pacman_oracle thousands of times with condition = true, priming the CPU’s Branch History Buffer (BHB).
2. The attacker then passes condition = false, but forces the variable condition to be evicted from cache so that reading it incurs a 150-cycle DRAM latency miss.
3. While the CPU stalls waiting for condition to resolve, Apple Silicon’s aggressive out-of-order execution engine predicts the branch as “taken” and speculatively executes the autia instruction using the attacker’s arbitrary guessed PAC value!

4. Cache Eviction & Microarchitectural Oracles: Leaking Keys Without Crashes

What happens inside the speculative pipeline depends entirely on whether the attacker’s 16-bit PAC guess was correct:

• Scenario A: Incorrect Guess (Wrong PAC): The speculative autia instruction detects a MAC mismatch and intentionally corrupts the upper address bits of the pointer. When the subsequent line attempts to load from the corrupted pointer (*verified_ptr), the hardware MMU catches a translation fault. The CPU suspends execution of that pipeline strand. The dependent load into probe_array is never executed. Moments later, the CPU discovers the branch misprediction, flushes the pipeline, and silently purges the fault without crashing!
• Scenario B: Correct Guess (Valid PAC): The speculative autia instruction verifies the signature perfectly! It strips the high PAC bits, leaving a pristine valid 48-bit pointer. The CPU executes the memory load, retrieves the byte, and executes the transmission load: probe_array[secret_byte * 4096]. This operation pulls that specific cache line into the CPU’s L1 Data Cache. When the branch misprediction is finally resolved, the architectural registers are flushed, but the physical cache state remains altered!

Now the attacker simply measures the memory access latency of probe_array[secret_byte * 4096] using standard Prime+Probe or Flush+Reload techniques:

• If access time is ~80 nanoseconds (DRAM Cache Miss): The PAC guess was incorrect. The system did not crash.
• If access time is ~4 nanoseconds (L1 Cache Hit): The PAC guess was 100% correct! The attacker has successfully cracked the cryptographic signature!

Because incorrect guesses result in silent cache misses rather than fatal operating system crashes, the attacker can iterate through candidate PAC values in a simple loop. On an Apple M1 Max processor, testing a single PAC guess takes less than 2.5 milliseconds. Testing all 65,536 combinations to find the unique valid cryptographic signature takes less than 2.6 minutes!

5. Exploit Telemetry: Memory Defenses Compared Under Speculation

The following microarchitectural security matrix contrasts modern memory corruption defenses against both architectural and speculative attack techniques:

6. Silicon Remediation: Why Software Patches Cannot Fully Cure PACMAN

When MIT disclosed PACMAN (cataloged under CVE-2022-26702), the vulnerability provoked immediate debate across the semiconductor industry. Because PACMAN targets the fundamental interaction between two independent hardware architectural features—out-of-order speculative execution and cryptographic pointer authentication—it cannot be permanently fixed with software patches without devastating performance consequences.

To completely eliminate PACMAN in software, operating system kernels and compilers would be forced to insert a full speculation barrier instruction (such as DSB SY followed by ISB on ARM64) immediately before every single pointer authentication call. This halts out-of-order execution, forcing the processor core to flush its pipelines and sit completely idle until the branch condition architecturally verifies against memory. Benchmarks reveal that inserting speculation barriers before every PAC verification results in a 20% to 35% collapse in instructions-per-clock (IPC) throughput, destroying the very performance advantage that makes Apple Silicon compelling.

Consequently, true remediation requires silicon-level microarchitectural redesign: future processor generations must implement Speculation-Aware Cryptographic Engines where the CPU execution units track the speculative status of signed pointers. If an instruction attempts to execute or dereference a pointer whose PAC validity has not yet architecturally committed, the CPU must stall memory dispatch until the branch retires, neutralizing the side-channel oracle while preserving high-speed out-of-order pipelining.

6.5 Microarchitectural Breakdown: Apple Firestorm/Avalanche Speculative Load Forwarding

To understand why the PACMAN attack executes with such devastating mathematical precision on Apple Silicon, one must examine the specific out-of-order execution engine implemented within Apple’s high-performance CPU cores (Firestorm in M1/A14, Avalanche in M2/A15, and Everest in M3/A16). Apple’s microarchitecture features the widest decode and execution pipeline in the commercial semiconductor industry—an 8-wide decode frontend backed by an astonishingly massive 630-entry Reorder Buffer (ROB) in Firestorm (expanding to over 640 entries in M2 and M3), dwarfing the 512-entry ROB of Intel Golden Cove and 320-entry ROB of AMD Zen 4.

This unprecedented ROB window allows Apple Silicon cores to speculatively dispatch, execute, and hold in-flight hundreds of instructions ahead of retirement. When an indirect branch instruction evaluates an authenticated pointer:

Crucially, while the architectural registers (X0–X30, SP, PC) are pristine and restored to their pre-speculative state without a single kernel panic, the physical cache line remains cached in L1D! The architectural rollback does not un-fetch cache lines. By executing a high-precision timer loop using the virtual counter register (CNTVCT_EL0), the PACMAN exploit measures access latency across candidate memory locations: an access completing in ~3 to 4 CPU cycles indicates an L1D cache hit (correct PAC guess), while an access requiring ~25 to 30 cycles indicates an L2 hit or main memory miss (incorrect PAC guess).

6.6 Comparative Security Audit: PAC Implementations Across Arm & Apple Silicon

The vulnerability exposed by PACMAN highlights a fundamental architectural trade-off: balancing nanosecond pointer authentication latency against speculative side-channel immunity. The table below details how pointer authentication primitives are deployed across modern hardware platforms and their susceptibility to speculative oracle attacks:

7. Institutional FAQ: Microarchitectural Security Q&A