Configuring per-process PAC key uniqueness for AArch64 user space

Per-process PAC key uniqueness on AArch64 Linux

On AArch64 Linux, the kernel can assign distinct Pointer Authentication (PAC) key configurations to each EL0 process. This is not an ARMv8.3-A hardware mandate; the architecture defines key registers per exception level and delegates the allocation policy to software. Linux implements per-process key isolation as part of its normal task-switch path, so a signed pointer created in one process will fail authentication if reused in another process that holds different keys.

Likely explanation vs confirmed facts

Likely explanation (OS policy): The kernel generates fresh PAC key selections at process execution (execve) or after fork+exec, stores the enabled-key bitmap in thread_info, and writes the corresponding key registers (APIAKey, APDAKey, etc.) during every context switch into the new task. While one process runs, its keys occupy the PAC registers; when the scheduler switches to another process, the kernel reloads that process's keys, rendering the previous process's signed pointers invalid.

Confirmed facts (model-knowledge research brief): ARMv8.3-A provides five 128-bit PAC key registers accessible at each exception level. Linux's prctl interface (PR_PAC_SET_ENABLED_KEYS, PR_PAC_GET_ENABLED_KEYS) lets user space query and activate key subsets. The kernel's switch_to and restore_regs paths include writing these registers from per-task state. Per-process keys change the threat model: a signed pointer leaked from process A cannot be replayed in process B because B's key differs, turning cross-process pointer forgery into a key-guessing problem with a 2^128 key space (minus tag bits).

Steps needed for this case

1. Verify hardware support: check /proc/cpuinfo or getconf HWCAP for PAC-related flags such as HWCAP_PACA or HWCAP_PACG. Absence of these flags means PAC is not available and the kernel falls back to a no-op.
2. Confirm kernel configuration and version: ensure the kernel is built with CONFIG_ARM64_PTR_AUTH and is a version that includes PAC user-space key management. Behavior varies across kernel releases, and older or minimal configurations may not enable per-process key switching.
3. At exec, confirm keys are freshly enabled: run prctl PR_PAC_GET_ENABLED_KEYS in a freshly executed binary to see which key subsets the kernel activated.
4. During context switch, the kernel writes the incoming task's key registers before resuming user mode. This is part of the standard register-restore path and does not require user-space intervention.
5. Validate cross-process isolation: sign a pointer with pacia in Process A, transfer the signed value to Process B, and execute autia in B. Expect a PAC authentication fault or trap in B if keys differ.

Missing diagnostic detail

Which kernel major version are you running, and do the /proc/cpuinfo flags show PAC-related hwcap bits? This determines whether the described switch-path behavior is present or if you are falling back to a no-op.