-ARMv8.3 Pointer Authentication in xnu
-=====================================
-
-Introduction
-------------
-
-This document describes xnu's use of the ARMv8.3-PAuth extension. Specifically,
-xnu uses ARMv8.3-PAuth to protect against Return-Oriented-Programming (ROP)
-and Jump-Oriented-Programming (JOP) attacks, which attempt to gain control flow
-over a victim program by overwriting return addresses or function pointers
-stored in memory.
-
-It is assumed the reader is already familar with the basic concepts behind
-ARMv8.3-PAuth and what its instructions do. The "ARMv8.3-A Pointer
-Authentication" section of Google Project Zero's ["Examining Pointer
-Authentication on the iPhone
-XS"](https://googleprojectzero.blogspot.com/2019/02/examining-pointer-authentication-on.html)
-provides a good introduction to ARMv8.3-PAuth. The reader may find more
-comprehensive background material in:
-
-* The "Pointer authentication in AArch64 state" section of the [ARMv8
- ARM](https://developer.arm.com/docs/ddi0487/latest/arm-architecture-reference-manual-armv8-for-armv8-a-architecture-profile)
- describes the new instructions and registers associated with ARMv8.3-PAuth.
-
-* [LLVM's Pointer Authentication
- documentation](https://github.com/apple/llvm-project/blob/apple/master/clang/docs/PointerAuthentication.rst)
- outlines how clang uses ARMv8.3-PAuth instructions to harden key C, C++,
- Swift, and Objective-C language constructs.
-
-### Threat model
-
-Pointer authentication's threat model assumes that an attacker has found a gadget
-to read and write arbitrary memory belonging to a victim process, which may
-include the kernel. The attacker does *not* have the ability to execute
-arbitrary code in that process's context. Pointer authentication aims to
-prevent the attacker from gaining control flow over the victim process by
-overwriting sensitive pointers in its address space (e.g., return addresses
-stored on the stack).
-
-Following this threat model, xnu takes a two-pronged approach to prevent the
-attacker from gaining control flow over the victim process:
-
-1. Both xnu and first-party binaries are built with LLVM's `-arch arm64e` flag,
- which generates pointer-signing and authentication instructions to protect
- addresses stored in memory (including ones pushed to the stack). This
- process is generally transparent to xnu, with exceptions discussed below.
-
-2. On exception entry, xnu hashes critical register state before it is spilled
- to memory. On exception return, the reloaded state is validated against this
- hash.
-
-The ["xnu PAC infrastructure"](#xnu-pac-infrastructure) section discusses how
-these hardening techniques are implemented in xnu in more detail.
-
-
-Key generation on Apple CPUs
-----------------------------
-
-ARMv8.3-PAuth implementations may use an <span style="font-variant:
-small-caps">implementation defined</span> cipher. Apple CPUs implement an
-optional custom cipher with two key-generation changes relevant to xnu.
-
-
-### Per-boot diversifier
-
-Apple's optional cipher adds a per-boot diversifier. In effect, even if xnu
-initializes the "ARM key" registers (`APIAKey`, `APGAKey`, etc.) with constants,
-signing a given value will still produce different signatures from boot to boot.
-
-
-### Kernel/userspace diversifier
-
-Apple CPUs also contain a second diversifier known as `KERNKey`. `KERNKey` is
-automatically mixed into the final signing key (or not) based on the CPU's
-exception level. When xnu needs to sign or authenticate userspace-signed
-pointers, it uses the `ml_enable_user_jop_key` and `ml_disable_user_jop_key`
-routines to manually enable or disable `KERNKey`. `KERNKey` allows the CPU to
-effectively use different signing keys for userspace and kernel, without needing
-to explicitly reprogram the generic ARM keys on every kernel entry and exit.
-
-
-xnu PAC infrastructure
-----------------------
-
-For historical reasons, the xnu codebase collectively refers to xnu + iOS's
-pointer authentication infrastructure as Pointer Authentication Codes (PAC). The
-remainder of this document will follow this terminology for consistency with
-xnu.
-
-### arm64e binary "slice"
-
-Binaries with PAC instructions are not fully backwards-compatible with non-PAC
-CPUs. Hence LLVM/iOS treat PAC-enabled binaries as a distinct ABI "slice" named
-arm64e. xnu enforces this distinction by disabling the PAC keys when returning
-to non-arm64e userspace, effectively turning ARMv8.3-PAuth auth and sign
-instructions into no-ops (see the ["SCTLR_EL1"](#sctlr-el1) heading below for
-more details).
-
-### Kernel pointer signing
-
-xnu is built with `-arch arm64e`, which causes LLVM to automatically sign and
-authenticate function pointers and return addresses spilled onto the stack. This
-process is largely transparent to software, with some exceptions:
-
-- During early boot, xnu rebases and signs the pointers stored in its own
- `__thread_starts` section (see `rebase_threaded_starts` in
- `osfmk/arm/arm_init.c`).
-
-- As parts of the userspace shared region are paged in, the page-in handler must
- also slide and re-sign any signed pointers stored in it. The ["Signed
- pointers in shared regions"](#signed-pointers-in-shared-regions) section
- discusses this in further detail.
-
-- Assembly routines must manually sign the return address with `pacibsp` before
- pushing it onto the stack, and use an authenticating `retab` instruction in
- place of `ret`. xnu provides assembly macros `ARM64_STACK_PROLOG` and
- `ARM64_STACK_EPILOG` which emit the appropriate instructions for both arm64
- and arm64e targets.
-
- Likewise, branches in assembly to signed C function pointers must use the
- authenticating `blraa` instruction in place of `blr`.
-
-- Signed pointers must be stripped with `ptrauth_strip` before they can be
- compared against compile-time constants like `VM_MIN_KERNEL_ADDRESS`.
-
-### Testing data pointer signing
-
-xnu contains tests for each manually qualified data pointer that should be
-updated as new pointers are qualified. The tests allocate a structure
-containing a __ptrauth qualified member, and write a pointer to that member.
-We can then compare the stored value, which should be signed, with a manually
-constructed signature. See `ALLOC_VALIDATE_DATA_PTR`.
-
-Tests are triggered by setting the `kern.run_ptrauth_data_tests` sysctl. The
-sysctl is implemented, and BSD structures are tested, in `bsd/tests/ptrauth_data_tests_sysctl.c`.
-Mach structures are tested in `osfmk/tests/ptrauth_data_tests.c`.
-
-### Managing PAC register state
-
-xnu generally tries to avoid reprogramming the CPU's PAC-related registers on
-kernel entry and exit, since this could add significant overhead to a hot
-codepath. Instead, xnu uses the following strategies to manage the PAC register
-state.
-
-#### A keys
-
-Userspace processes' A keys (`AP{IA,DA,GA}Key`) are derived from the field
-`jop_pid` inside `struct task`. For implementation reasons, an exact duplicate
-of this field is cached in the corresponding `struct machine_thread`.
-
-
-A keys are randomly generated at shared region initialization time (see ["Signed
-pointers in shared regions"](#signed-pointers-in-shared-regions) below) and
-copied into `jop_pid` during process activation. This shared region, and hence
-associated A keys, may be shared among arm64e processes under specific
-circumstances:
-
-1. "System processes" (i.e., processes launched from first-party signed binaries
- on the iOS system image) generally use a common shared region with a default
- `jop_pid` value, separate from non-system processes.
-
- If a system process wishes to isolate its A keys even from other system
- processes, it may opt into a custom shared region using an entitlement in
- the form `com.apple.pac.shared_region_id=[...]`. That is, two processes with
- the entitlement `com.apple.pac.shared_region_id=foo` would share A keys and
- shared regions with each other, but not with other system processes.
-
-2. Other arm64e processes automatically use the same shared region/A keys if
- their respective binaries are signed with the same team-identifier strings.
-
-3. `posix_spawnattr_set_ptrauth_task_port_np()` allows explicit "inheriting" of
- A keys during `posix_spawn()`, using a supplied mach task port. This API is
- intended to support debugging tools that may need to auth or sign pointers
- using the target process's keys.
-
-#### B keys
-
-Each process is assigned a random set of "B keys" (`AP{IB,DB}Key`) on process
-creation. As a special exception, processes which inherit their parents' memory
-address space (e.g., during `fork`) will also inherit their parents' B keys.
-These keys are stored as the field `rop_pid` inside `struct task`, with an exact
-duplicate in `struct machine_thread` for implementation reasons.
-
-xnu reprograms the ARM B-key registers during context switch, via the macro
-`set_process_dependent_keys_and_sync_context` in `cswitch.s`.
-
-xnu uses the B keys internally to sign pointers pushed onto the kernel stack,
-such as stashed LR values. Note that xnu does *not* need to explicitly switch
-to a dedicated set of "kernel B keys" to do this:
-
-1. The `KERNKey` diversifier already ensures that the actual signing keys are
- different between xnu and userspace.
-
-2. Although reprogramming the ARM B-key registers will affect xnu's signing keys
- as well, pointers pushed onto the stack are inherently short-lived.
- Specifically, there will never be a situation where a stack pointer value is
- signed with one `current_task()`, but needs to be authed under a different
- active `current_task()`.
-
-#### SCTLR_EL1
-
-As discussed above, xnu disables the ARM keys when returning to non-arm64e
-userspace processes. This is implemented by manipulating the `EnIA`, `EnIB`,
-and `EnDA`, and `EnDB` bits in the ARM `SCTLR_EL1` system register. When
-these bits are cleared, auth or sign instruction using the respective keys
-will simply pass through their inputs unmodified.
-
-Initially, xnu cleared these bits during every `exception_return` to a
-non-arm64e process. Since xnu itself uses these keys, the exception vector
-needs to restore the same bits on every exception entry (implemented in the
-`EL0_64_VECTOR` macro).
-
-Apple A13 CPUs now have controls that allow xnu to keep the PAC keys enabled at
-EL1, independent of `SCTLR_EL1` settings. On these CPUs, xnu only needs to
-reconfigure `SCTLR_EL1` when context-switching from a "vanilla" arm64 process to
-an arm64e process, or vice-versa (`pmap_switch_user_ttb_internal`).
-
-### Signed pointers in shared regions
-
-Each userspace process has a *shared region* mapped into its address space,
-consisting of code and data shared across all processes of the same processor
-type, bitness, root directory, and (for arm64e processes) team ID. Comments at
-the top of `osfmk/vm/vm_shared_region.c` discuss this region, and the process of
-populating it, in more detail.
-
-As the VM layer pages in parts of the shared region, any embedded pointers must
-be rebased. Although this process is not new, PAC adds a new step: these
-embedded pointers may be signed, and must be re-signed after they are rebased.
-This process is implemented as `vm_shared_region_slide_page_v3` in
-`osfmk/vm/vm_shared_region.c`.
-
-xnu signs these embedded pointers using a shared-region-specific A key
-(`sr_jop_key`), which is randomly generated when the shared region is created.
-Since these pointers will be consumed by userspace processes, xnu temporarily
-switches to the userspace A keys when re-signing them.
-
-### Signing spilled register state
-
-xnu saves register state into kernel memory when taking exceptions, and reloads
-this state on exception return. If an attacker has write access to kernel
-memory, it can modify this saved state and effectively get control over a
-victim thread's control flow.
-
-xnu hardens against this attack by calling `ml_sign_thread_state` on exception
-entry to hash certain registers before they're saved to memory. On exception
-return, it calls the complementary `ml_check_signed_state` function to ensure
-that the reloaded values still match this hash. `ml_sign_thread_state` hashes a
-handful of particularly sensitive registers:
-
-* `pc, lr`: directly affect control-flow
-* `cpsr`: controls process's exception level
-* `x16, x17`: used by LLVM to temporarily store unauthenticated addresses
-
-`ml_sign_thread_state` also uses the address of the thread's `arm_saved_state_t`
-as a diversifier. This step keeps attackers from using `ml_sign_thread_state`
-as a signing oracle. An attacker may attempt to create a sacrificial thread,
-set this thread to some desired state, and use kernel memory access gadgets to
-transplant the xnu-signed state onto a victim thread. Because the victim
-process has a different `arm_saved_state_t` address as a diversifier,
-`ml_check_signed_state` will detect a hash mismatch in the victim thread.
-
-Apart from exception entry and return, xnu calls `ml_check_signed_state` and
-`ml_sign_thread_state` whenever it needs to mutate one of these sensitive
-registers (e.g., advancing the PC to the next instruction). This process looks
-like:
-
-1. Disable interrupts
-2. Load `pc, lr, cpsr, x16, x17` values and hash from thread's
- `arm_saved_state_t` into registers
-3. Call `ml_check_signed_state` to ensure values have not been tampered with
-4. Mutate one or more of these values using *only* register-to-register
- instructions
-5. Call `ml_sign_thread_state` to re-hash the mutated thread state
-6. Store the mutated values and new hash back into thread's `arm_saved_state_t`.
-7. Restore old interrupt state
-
-Critically, none of the sensitive register values can be spilled to memory
-between steps 1 and 7. Otherwise an attacker with kernel memory access could
-modify one of these values and use step 5 as a signing oracle. xnu implements
-these routines entirely in assembly to ensure full control over register use,
-using a macro `MANIPULATE_SIGNED_THREAD_STATE()` to generate boilerplate
-instructions.
-
-Interrupts must be disabled whenever `ml_check_signed_state` or
-`ml_sign_thread_state` are called, starting *before* their inputs (`x0`--`x5`)
-are populated. To understand why, consider what would happen if the CPU could
-be interrupted just before step 5 above. xnu's exception handler would spill
-the entire register state to memory. If an attacker has kernel memory access,
-they could attempt to replace the spilled `x0`--`x5` values. These modified
-values would then be reloaded into the CPU during exception return; and
-`ml_sign_thread_state` would be called with new, attacker-controlled inputs.
-
-### thread_set_state
-
-The `thread_set_state` call lets userspace modify the register state of a target
-thread. Signed userspace state adds a wrinkle to this process, since the
-incoming FP, LR, SP, and PC values are signed using the *userspace process's*
-key.
-
-xnu handles this in two steps. First, `machine_thread_state_convert_from_user`
-converts the userspace thread state representation into an in-kernel
-representation. Signed values are authenticated using `pmap_auth_user_ptr`,
-which involves temporarily switching to the userspace keys.
-
-Second, `thread_state64_to_saved_state` applies this converted state to the
-target thread. Whenever `thread_state64_to_saved_state` modifies a register
-that makes up part of the thread state hash, it uses
-`MANIPULATE_SIGNED_THREAD_STATE()` as described above to update this hash.
-
-
-### Signing arbitrary data blobs
-
-xnu provides `ptrauth_utils_sign_blob_generic` and `ptrauth_utils_auth_blob_generic`
-to sign and authenticate arbitrary blobs of data. Callers are responsible for
-storing the pointer-sized signature returned. The signature is a rolling MAC
-of the data, using the `pacga` instruction, mixed with a provided salt and optionally
-further diversified by storage address.
-
-Use of these functions is inherently racy. The data must be read from memory
-before each pointer-sized block can be added to the signature. In normal operation,
-standard thread-safety semantics protect from corruption, however in the malicious
-case, it may be possible to time overwriting the buffer before signing or after
-authentication.
-
-Callers of these functions must take care to minimise these race windows by
-using them immediately preceeding/following a write/read of the blob's data.
projects / apple / xnu.git / commitdiff
