pointer authentication
/ PAK /
When you sign a cheque, the signature lets the bank detect a forgery: alter the amount and the signature no longer matches. Pointer authentication (PAC), an ARM feature, applies that idea to pointers. Before a pointer (especially a return address or a function pointer) is stored to memory, the CPU computes a cryptographic signature over it and tucks that signature into the pointer's own unused high bits; before the pointer is used, the CPU verifies the signature. If an attacker has tampered with the pointer in between, the signature check fails.
Here is how it fits in a 64-bit address. Real virtual addresses use only the low bits (say 48), leaving the top bits unused. PAC stuffs a Pointer Authentication Code — a keyed cryptographic tag computed from the pointer value, a secret key held in the CPU, and a context value such as the stack pointer — into those spare high bits. New instructions do the work: pacia signs a pointer, autia authenticates (and strips the tag from) it. A function's prologue signs the return address with paciasp; its epilogue authenticates it with autiasp before the ret. If a buffer overflow overwrote the saved return address with an attacker's value, that value carries no valid signature for this context, so authentication fails and dereferencing the now-corrupt pointer faults. Because the signing key never leaves the CPU and is unknown to the attacker, they cannot forge a valid tag for an arbitrary address.
It matters because it protects both return addresses (backward edge) and code/function pointers (forward edge) with low overhead and is widely deployed (notably on Apple's ARM chips), blunting ROP and pointer-corruption attacks at their root. The honest caveats: PAC is not a full guarantee. The tag is only as many bits as are spare (often 11 to 16), so a blind guess succeeds with small but nonzero probability; a SIGNING ORACLE (a code path the attacker can make sign a pointer of their choosing) or a key leak breaks it; and reusing a validly-signed pointer in a different context (a pointer-reuse or 'PACMAN'-style speculative attack) can sidestep it. It is a strong, cheap layer, not an absolute one.
; ARM64 function with PAC-protected return address: paciasp ; prologue: sign return addr (lr) using SP as context ... ; body; an overflow may clobber the saved lr autiasp ; epilogue: authenticate; fails if lr was tampered with ret ; only a validly-signed return address survives
paciasp/autiasp bracket the function: a tampered return address fails authentication before ret uses it.
PAC's tag has only a handful of bits, so it is probabilistic, and a signing oracle or key leak defeats it; it raises the cost of pointer forgery sharply but is not an unconditional guarantee.