A Reverse Engineer’s Anatomy of the macOS Boot Chain & Security Architecture

1.0 The Silicon Root of Trust: Pre-Boot & Hardware Primitives

The security of the macOS platform on Apple Silicon is not defined by the kernel; it is defined by the physics of the die. Before the first instruction of kernelcache is fetched, a complex, cryptographic ballet has already concluded within the Application Processor (AP). This section dissects the immutable hardware logic that establishes the initial link in the Chain of Trust.

1.1 The Reset Vector & Boot ROM (SecureROM)

The Apple Silicon boot process begins in a state of absolute trust, anchored by the Boot ROM (often colloquially referred to as SecureROM). This code is mask-programmed into the silicon during fabrication. It is immutable, unpatchable, and serves as the hardware root of trust for the entire platform.

1.1.1 Execution at Reset: Analyzing the Reset Vector (`RVBAR_ELx`)

Upon Power-On Reset (POR), the cores of the M-series SoC (and A-series) initialize in the highest privilege state implemented by the microarchitecture. In the Armv8/v9 architecture, this role is architecturally associated with Exception Level 3 (EL3) and its reset vector register family RVBAR_ELx. On Apple Silicon, public reverse engineering strongly suggests that Apple does not expose a persistent, software-visible EL3 monitor in the style of classical TrustZone. Instead, the Application Processor (AP) Boot ROM executes in an implementation-defined reset context that has strictly higher privilege than the runtime EL2/EL1 kernel environment and is the only code allowed to touch certain secure configuration registers.

For the purposes of this discussion, the important property is not the exact architectural EL label, but that the Boot ROM runs in a one-shot, highest-privilege reset context that:

owns the reset vector (RVBAR_ELx) and initial exception state, and
can program security-critical registers that are later hidden from or read-only to EL2/EL1.

The execution flow begins at the address defined in the Reset Vector Base Address Register (one of the RVBAR_ELx registers, depending on the concrete implementation). Reverse engineering of recent Apple Silicon (M1/M2/M3) indicates the memory map places the Boot ROM at a high base address, typically observed around 0x100000000.

The Initial Instruction Stream:

The very first instructions executed by the silicon are responsible for establishing a sane C execution environment from a raw hardware state. Analysis of the entry point in similar Apple SoCs reveals a standard initialization sequence:

Interrupt Masking: The DAIF bits are set to mask all interrupts (IRQ, FIQ, SError, Debug). The Boot ROM operates in a strictly polled mode; interrupts are nondeterministic and introduce attack surface.
Cache Invalidation: The instruction and data caches are invalidated to prevent cold-boot attacks or stale data usage.
Stack Setup: The Stack Pointer for the reset context (architecturally SP_EL3, but on Apple Silicon effectively the highest-privilege stack pointer) is initialized to point to a dedicated region of on-chip SRAM. DRAM is not initialized at this stage. The Boot ROM runs entirely within the constraints of the SoC’s internal SRAM.
MMU Configuration: The System Control Register for the reset context (SCTLR_ELx at the highest implemented level) is programmed to enable the MMU, mapping the Boot ROM text as Read-Only/Executable and the SRAM stack/heap as Read-Write/No-Execute.

RE Note: Apple’s high-privilege reset context is ephemeral. There is no persistent EL3 monitor analogous to Qualcomm’s QSEE. Once the Boot ROM has initialized hardware, validated and decrypted the next stage, and “demoted” the core into the runtime EL2/EL1 regime, the reset context is no longer reachable. Subsequent firmware (LLB, iBoot, XNU) can observe the effects of its configuration but cannot re-enter that privilege level or read back the Boot ROM contents directly.

1.1.2 The GID Key (Group ID): Hardware-entangled Decryption

The Boot ROM’s primary objective is to load the Low-Level Bootloader (LLB). However, the LLB stored on the boot medium is not a raw binary; it is wrapped in an Image4 (img4) container, and its payload (IM4P) is both encrypted and, on production devices, personalized.

At the heart of this process is the GID Key (Group ID Key).

The GID Key is a 256-bit AES key fused into the silicon during manufacturing. It is shared across processors of the same class (e.g., all M3 Pro chips share a GID, distinct from M3 Max), and it never leaves the confines of the on-die crypto hardware.

KBAG Unwrapping: GID as a Wrapping Key

Image4 payloads do not store the LLB ciphertext encrypted “directly under GID.” Instead, they contain an embedded Keybag (KBAG): a small structure that holds per-image AES keys and IVs encrypted under the GID (and, where applicable, UID) keys.

The flow is:

Manifest & Payload Parsing:
The Boot ROM parses the Image4 container, separates the IM4M (Manifest) from the IM4P (Payload), and locates the KBAG for the LLB within IM4P.
KBAG Decryption (GID Slot):
The KBAG consists of one or more wrapped key records (e.g., development vs. production keys). To unwrap the appropriate record, the Boot ROM:
- Writes the KBAG ciphertext (the wrapped IV+key material) into the AES engine’s input FIFO.
- Programs the AES configuration register to use the GID key slot as the decryption source (a “use GID” control bit or mode selector).
- Triggers the engine. The hardware AES block internally reads the GID key from fuses, decrypts the KBAG fragment, and emits the plaintext IV and AES key for the LLB.
The GID value itself is never exposed to software; only the result of the KBAG unwrap is visible.
LLB Payload Decryption (Target Key):
With the per-image AES key and IV recovered from the KBAG, the Boot ROM then decrypts the LLB payload:
- It configures the AES engine (or, on some generations, uses the ARMv8 AES instructions) with the target key obtained from the KBAG.
- It streams the LLB ciphertext through this AES context into SRAM, yielding the plaintext LLB image.
Zeroization:
After decryption, the AES hardware clears any internal registers holding the GID-derived material. The Boot ROM code has no mechanism to read back the GID key and no direct path to expose the target key outside the immediate decryption context.

This two-stage scheme (GID → KBAG → LLB) is what makes the system hardware-entangled: the cryptographic key that ultimately decrypts the bootloader exists only as the output of a GID-protected unwrap on that class of silicon.

Exploit Implication:

Even if an attacker gains arbitrary code execution inside the Boot ROM (as in checkm8-class vulnerabilities on earlier A-series devices), they still cannot extract the raw GID key and cannot perform offline decryption of production firmware:

The GID key is never mapped into general-purpose registers or memory.
The only decryption primitive available is “unwrap KBAG under GID,” running inside the AES peripheral.
Firmware images must be decrypted on-device, with the AES engine acting as a constrained decryption oracle at best, and only for keys/payloads consistent with the KBAG format accepted by the ROM.

1.1.3 The Public Key Accelerator (PKA): Hardware-Enforced Verification

Decryption provides confidentiality, but not integrity. To prevent the execution of malicious firmware, the Boot ROM enforces strict code signing using the Public Key Accelerator (PKA).

The PKA is a dedicated hardware block optimized for asymmetric cryptography (RSA and ECC). The verification flow is as follows:

Root of Trust: The Apple Root CA public key is embedded directly within the immutable Boot ROM code. This serves as the anchor for the chain of trust.
Manifest Parsing: The Boot ROM parses the Image4 (img4) container of the LLB. It extracts the Image4 Manifest (IM4M), which contains the payload's signature and the certificate chain used to sign it.
Key Verification: The Boot ROM validates the certificate chain found in the manifest against the Root CA embedded in the ROM. If the chain is invalid or does not lead back to the hardware anchor, the boot halts (the device typically enters DFU/Recovery mode).
Signature Verification: The Boot ROM offloads the signature verification to the PKA. It passes the hash of the payload (typically SHA-2 family) and the RSA/ECC signature. The PKA performs the mathematical verification. Architectural inference and reverse engineering suggest it returns a boolean result to a status register, although this specific implementation detail is not explicitly defined in public Apple documentation.

Fault Injection Hardening:
Analysis of recent Apple Boot ROMs suggests the implementation of glitch-resistant logic around the PKA check. Rather than a simple B.EQ (Branch if Equal) instruction following the PKA result—which could be bypassed via voltage glitching—reverse engineering indicates the code often employs redundant checks, loop invariants, or specific register values that must be populated by the PKA hardware itself to allow the boot flow to proceed.

1.1.4 RE Focus: Dev vs. Prod Fused Silicon

For reverse engineering and exploit development, distinguishing Development (Dev-fused) from Production (Prod) silicon is critical. The Boot ROM and security subsystem change behavior based on fuse fields that encode the security domain of the chip.

A central knob here is Apple’s CPFM field (“Chip Production / Firmware Mode”), burned into fuses and exposed in various debug logs and DFU responses.

CPFM Observations:

Across multiple generations, public Boot ROM banners and tooling logs show a consistent pattern:

CPFM 0x0 / 0x1:
Used for development or internal security domains:
- Enable richer debug visibility.
- Allow additional boot modes and demotion paths.
- Often relax some signature enforcement or allow alternate signing roots for internal firmware.
CPFM 0x3:
Standard production configuration for consumer devices:
- Full signature enforcement for all boot stages.
- No public demotion path.
- Debug interfaces (JTAG/SWD) and invasive trace disabled or tightly restricted.

The exact semantics of intermediary values (e.g., 0x2) and the precise bit-level encoding are SoC- and generation-specific, but the broad distinction above is stable across published ROM dumps and DFU tooling.

Production (CPFM ≈ 0x3):

This is the configuration for retail hardware:

JTAG / SWD: Disabled or heavily locked. External debug probes cannot halt the core at reset in any supported way.
GID Behavior: The GID key is set to the production group value, shared only across chips of the same class, and never accessible via software.
Boot Policy: The Boot ROM enforces the full Apple Root CA chain and Image4 constraints. Unsupported or revoked OS builds fail before DRAM initialization, dropping the device into DFU.

Development (CPFM ≈ 0x0 / 0x1):

Dev-fused devices, including security research units and internal engineering hardware, typically relax some of these constraints:

JTAG Enablement: The DBGEN / SPIDEN debug signals are asserted. Hardware debuggers (Lauterbach, Astris, etc.) can halt the core immediately after reset and single-step Boot ROM code.
Demotion: Dev-fused chips can usually enter “demoted” modes where unsigned or custom-signed firmware images are bootable. The exact mechanisms (special DFU commands, provisioning profiles, or special Image4 manifests) are implementation details, but the high-level effect is that certain signature and version checks are bypassed or altered for internal workflows.
GID Key Variance: Dev silicon often uses a distinct GID key (or set of keys) from production. This means:
- Firmware encrypted for Prod cannot be decrypted on Dev, and vice versa.
- Dev images are cryptographically bound to dev-fused hardware, preventing accidental cross-leakage into production units.

Identifying Silicon State in Practice:

From the outside, the security domain can be inferred via DFU and other low-level interfaces:

DFU Responses:
USB DFU responses (e.g., from irecovery, ipwndfu, or equivalent tooling) expose fields such as CPID, ECID, and CPFM-like indicators. On many platforms:
- Values where CPFM-like bits are 0x3 correspond to production devices.
- Values where CPFM-like bits are 0x0 or 0x1 correspond to dev-fused hardware.
CHIP_ID / ECID Patterns:
Reverse-engineering tools often apply heuristic masks to these fields to classify devices. For example, certain high bits set in CHIP_ID or specific ranges in ECID are empirically associated with production vs. development, but the exact encodings vary by SoC and should be treated as version-specific heuristics rather than universal rules.

The “Un-dumpable” Region:

Regardless of dev or prod state, once the Boot ROM prepares to jump to the next stage (LLB), it typically performs a lockdown sequence:

Writes to the memory controller or system registers to unmap its own address range (e.g., around 0x100000000) from the normal physical address space.
Ensures that any subsequent attempt by LLB or the kernel to read that region either raises a bus error or returns zeros.

This is why practical Boot ROM dumps require a vulnerability during the Boot ROM execution window (e.g., checkm8-style exploits or carefully timed glitching) rather than a simple read from a later boot stage. On production (CPFM ≈ 0x3) devices this window is tightly constrained; on dev-fused hardware, JTAG/SWD access and relaxed policy make that window significantly easier to instrument but do not fundamentally change the “self-erasing” behavior.

1.2 Proprietary ISA Extensions (arm64e+)

While the M-series cores implement the Armv8-A architecture with a comprehensive set of optional extensions (e.g., FEAT_PAuth, FEAT_BTI), Apple has aggressively extended the Instruction Set Architecture (ISA) with proprietary logic. For the reverse engineer, standard Arm documentation is insufficient. Understanding the security posture of macOS Tahoe requires mastering these custom extensions, as they form the hardware enforcement layer for the new kernel isolation model.

1.2.1 Pointer Authentication (PAC): The Cryptographic Control Flow

Apple’s implementation of Armv8.3-PAuth is the most pervasive security mitigation in the XNU kernel. It repurposes the unused high-order bits above the configured virtual address size (the "top" bits of a 64-bit pointer) to store a cryptographic signature, or Pointer Authentication Code (PAC).

The Key Hierarchy:
The hardware maintains five distinct 128-bit keys in system registers. On macOS with VHE (Virtualization Host Extensions) enabled, the kernel accesses these keys via the _EL1 register aliases, which the hardware redirects to the EL2 bank of the key registers:

APIAKey / APIBKey (Instruction): Signs code pointers (function pointers, return addresses).
APDAKey / APDBKey (Data): Signs data pointers. Crucial for protecting C++ vtables in IOKit (OSObject).
APGAKey (Generic): Signs arbitrary data blobs, effectively a hardware-accelerated MAC.

The AUT Failure Mechanism (Canonical Non-Valid):
For the reverse engineer analyzing crash dumps, understanding the failure mode is critical. When an AUT* instruction (e.g., AUTIA) is executed on a corrupted or forged pointer, the CPU does not immediately raise an exception.

Instead, the hardware corrupts the pointer in a deterministic way to ensure it causes a translation fault upon dereference.

Validation: The CPU recalculates the PAC.
Mismatch: If the calculated PAC does not match the bits in the pointer, the CPU writes an error pattern into the PAC field, flipping specific high-order bits.
Result: The pointer becomes a "canonical non-address": the PAC field is overwritten with an error pattern so that any use of the pointer leads to an architectural fault.
Crash: The subsequent LDR or BLR triggers a Data Abort or Prefetch Abort.

RE Tip: Empirically, on many M-series SoCs, a PAC authentication failure often manifests as a pointer where the upper byte is partially set (e.g., 0x007f... or 0x00ff...). If you see a crash involving such a pointer, you are likely looking at a PAC failure rather than a standard NULL dereference or heap corruption.

1.2.2 Branch Target Identification (BTI): The Landing Pads

Often deployed in tandem with PAC (-mbranch-protection=standard), BTI mitigates Jump-Oriented Programming (JOP). It enforces a state machine on indirect branches.

Marking Pages: The Page Table Entries (PTE) now include a Guarded Page (GP) bit.
The BTI Instruction: This is a "hint" instruction (NOP on older silicon). It acts as a valid landing pad.
Enforcement: When the CPU executes an indirect branch (BR, BLR) targeting a Guarded Page, the very next instruction must be a BTI instruction of the correct type (c for call, j for jump, jc for both).

If the target is not a BTI instruction, the CPU raises a Branch Target Exception. In XNU, observations suggest this often manifests as a SIGILL (Illegal Instruction) with a specific subcode, distinguishing it from standard undefined opcode exceptions. For exploit development, this necessitates finding gadgets that not only perform the desired operation but are also preceded by a valid landing pad.

1.2.3 New in Tahoe: The Guarded Execution Feature (GXF)

This is the most significant architectural divergence in the Apple Silicon era. Standard Arm defines a vertical privilege stack (EL0 → EL1 → EL2). Apple has introduced a parallel execution domain, conceptually a Secure World (distinct from Arm TrustZone), accessed via Guarded Levels (GL).

GXF allows the processor to switch between the "Normal World" (where macOS runs) and the "Secure World" (where Exclaves run). These worlds share the same physical silicon but possess vastly different hardware permissions and system register views.

The Privilege Hierarchy:
Guarded Levels (GL) do not merely mirror standard Exception Levels in a parallel context; GL2 maps directly to the hardware Exception Level 2 (EL2), effectively repurposing the architectural level for the monitor. The mapping for macOS Tahoe is as follows:

Normal World (macOS):
- EL0: Userland processes (Apps, Daemons).
- GL1 (Hardware EL1): The XNU Kernel. On M4 systems employing the Tahoe architecture, the Secure Page Table Monitor (SPTM) occupies the hardware EL2 (mapped to GL2). Consequently, the XNU kernel operates at GL1 (Hardware EL1) as a virtualized guest, rather than executing at EL2.
Secure World (Exclaves):
- GL0: Conclaves (secure user workloads) and a privileged Conclave hosting the Trusted Execution Monitor (TXM). This is where policy logic, privacy indicators, and Passkey logic reside.
- GL1: The Secure Kernel (ExclaveOS). An L4-inspired microkernel responsible for scheduling and IPC within the secure world.
- GL2 (Hardware EL2): The Secure Page Table Monitor (SPTM). The ultimate hardware root of trust, mirroring the privilege of a hypervisor but strictly for security enforcement.

The Proprietary Opcodes:
Transitions between worlds are not handled by standard SMC calls. Apple added custom instructions to the ISA:

GENTER (Opcode 0x00201420): Synchronous entry into the Secure World. It behaves like a hypercall, atomically switching the hardware context (SPRR state, stack pointer, and system registers) from ELx to GLx.
GEXIT (Opcode 0x00201400): Returns from the Secure World to the Normal World.

1.2.4 New in Tahoe: Shadow Permission Remapping Registers (SPRR)

To enforce isolation between the Normal World (XNU) and the Secure World (Exclaves), Apple replaced the older APRR (Access Permission Remapping Registers) on newer silicon (A15/M2+) with the more robust SPRR (Shadow Permission Remapping Registers).

In standard Arm MMUs, the Page Table Entry (PTE) bits define permissions directly. In Apple Silicon with SPRR enabled, the PTE's AP[1:0] bits and NX bits (UXN, PXN) are repurposed as a 4-bit index into a hardware permission table.

The Indirection Layer:

PTE Index: The PTE specifies a permission index (e.g., Index 5).
Context Lookup: The hardware checks the current execution mode (EL2, GL1, or GL2).
Resolution: It looks up Index 5 in the SPRR_PERM_ELx register specific to that mode.

The Security Implication:
This allows for "View-Based" memory protection.

A particular SPRR index (for example, index 5) is configured so that in GL2 (SPTM) it resolves to Read-Write (RW).
The same index resolves to Read-Only (RO) in EL2 (Kernel).

This is how the SPTM protects page tables. The physical pages containing the translation tables are marked with a specific SPRR index. The hardware configuration for EL2 (Kernel) maps that index to Read-Only. Even if an attacker has a kernel-level arbitrary write primitive, the MMU will reject the write to the page table because the SPRR configuration for EL2 forbids it. The only way to write to that page is to execute GENTER to switch to GL2, where the SPRR configuration permits the write.

2.0 The Secure Enclave Processor (SEP): The Parallel Computer

If the Application Processor (AP) is the brain of the device, the Secure Enclave Processor (SEP) is its conscience. It is not merely a coprocessor; it is a fully independent computer-on-a-chip, sharing the same die but architecturally severed from the AP. It runs its own operating system (sepOS), based on an Apple-customized L4 microkernel, manages its own peripherals, and holds the keys to the kingdom (UID/GID). In the macOS Tahoe generation, the SEP effectively acts as the root of authority for biometric authentication decisions and for OS-bound key material used in attestation and Data Protection.

2.1 SEP Initialization & Boot

The SEP boot process is designed to be resilient against a fully compromised Application Processor. From the moment power is applied, the SEP operates under the threat model that the AP is hostile.

2.1.1 The SEPROM: SRAM Execution and the Memory Protection Engine (MPE)

Like the AP, the SEP begins execution from an immutable on-die Boot ROM, the SEPROM.

The Hardware Environment:
The SEP core (historically an ARMv7-A "Kingfisher" core on A7–A9, though the specific microarchitecture of M-series SEP cores is undocumented) initializes in a highly constrained environment. Execution begins in the SEPROM using a small on-die SRAM for stack and early state. However, the sepOS is too large to fit entirely in SRAM. To utilize the device's main DRAM securely, the SEP relies on the Memory Protection Engine (MPE). Before the SEP accesses external DRAM, the Boot ROM initializes the MPE, ensuring all subsequent memory transactions are encrypted and authenticated. This isolation prevents early-boot DMA attacks from the AP or Thunderbolt peripherals.

The Memory Protection Engine (MPE):
The MPE sits inline between the SEP core and the memory controller. It creates a cryptographic window into physical memory that is opaque to the rest of the SoC.

Ephemeral Keys: On system startup, the SEP Boot ROM programs the MPE with a random, ephemeral AES key. This key exists only in the MPE hardware registers and is never exposed to software (even sepOS). On M-series silicon, the MPE manages distinct ephemeral keys for the SEP and the Secure Neural Engine (SNE), ensuring isolation even between secure subsystems.
AES-XEX Encryption: Data written by the SEP to DRAM is encrypted transparently using AES in XEX (XOR-Encrypt-XOR) mode.
Authentication: The MPE calculates a CMAC tag for every block of memory (cache line granularity). This tag is stored alongside the encrypted data.

RE Implication: If you attempt to dump the physical memory range assigned to the SEP from the AP (kernel mode), you will see high-entropy noise. Furthermore, any attempt to modify a single bit of this memory via the AP will invalidate the CMAC tag. The next time the SEP reads that line, the MPE will detect the forgery and trigger a hardware panic, locking down the Enclave until a full system reset.

2.1.2 The Boot Monitor: Hardware Enforcement of OS-Bound Keys

On modern silicon (A13/M1 and later), Apple introduced the Secure Enclave Boot Monitor to mitigate the risk of Boot ROM exploits (like checkm8) compromising the chain of trust for key derivation.

In older architectures, the SEPROM would verify the sepOS signature and then jump to it. If the SEPROM was exploited, the attacker could jump to a malicious payload while retaining access to the hardware UID key. The Boot Monitor closes this gap by enforcing System Coprocessor Integrity Protection (SCIP).

The Boot Flow:

Payload Staging: The AP (iBoot) loads the sep-firmware.img4 payload into a region of physical memory.
Mailbox Signal: The AP signals the SEP via a hardware mailbox register.
Verification: The SEPROM parses the Image4 container. It verifies the signature against the SEP-specific Apple Root CA public key embedded within the immutable SEPROM.
The Handoff: Crucially, the SEPROM cannot simply jump to the loaded image. The SCIP hardware prevents execution of mutable memory.
Monitor Intervention: The SEPROM invokes the Boot Monitor hardware block.
- The Monitor resets the SEP core to a known clean state.
- The Monitor calculates a cryptographic hash of the loaded sepOS memory range.
- The Monitor updates the SCIP registers to permit execution of that specific range.
- The Boot ROM and Boot Monitor jointly produce a measurement of the loaded sepOS and lock it into a dedicated register used by the Public Key Accelerator (PKA).

OS-Bound Key Derivation:
This finalized hash is the critical component. When the sepOS later requests keys (e.g., to decrypt user data), the hardware Key Derivation Function (KDF) mixes the hardware UID with this locked hash.

$$ K_{derived} = KDF(UID, Hash_{sepOS}) $$

If an attacker modifies a single byte of the sepOS (even with a Boot ROM exploit), the Boot Monitor calculates a different hash. Consequently, the KDF derives different OS-bound keys, so any data protected by those keys (e.g., passcode- and SKP-bound Data Protection keys) remains cryptographically inaccessible under the modified sepOS. This is "Bound Security"—the data is bound not just to the device, but to a specific, signed software version.

2.1.3 Anti-Replay Mechanisms: The Integrity Tree

A classic attack vector against secure enclaves is the Replay Attack: capturing a snapshot of the encrypted RAM (e.g., when the passcode retry counter is 0) and restoring it later after the counter has incremented.

To prevent this, the SEP implements a hardware-enforced Integrity Tree (Merkle Tree).

The Root of Trust: The root node of the integrity tree is stored in dedicated on-chip SRAM within the Secure Enclave complex. This memory is physically distinct from the main DRAM and cannot be addressed by the AP.
Tree Structure: The protected memory region (where sepOS data and the Secure Storage Manager reside) is divided into blocks. Each block's hash is stored in a parent node, recursively up to the root.
Atomic Updates: When the SEP writes to protected memory (e.g., incrementing a failed attempt counter), the MPE updates the data, recalculates the hashes up the tree, and atomically updates the root hash in the on-chip SRAM.
Verification: On every read, the MPE verifies the path from the data block up to the SRAM root.

If an attacker replays an old DRAM state, the hash of the replayed block will not match the current root hash stored in the internal SRAM. The MPE detects the mismatch (Anti-Replay Violation) and halts the SEP. This mechanism ensures that the SEP has a strictly monotonic view of time and state, rendering snapshot fuzzing and counter rollbacks impossible.

2.2 SEP Runtime Architecture

Once the sepOS is bootstrapped and verified, the Secure Enclave transitions into its runtime state. At this point, it functions as a fully autonomous operating system running an Apple-customized variant of the L4 microkernel (historically derived from L4-embedded/Darbat). For the reverse engineer, understanding the runtime architecture is crucial for analyzing how the SEP communicates with the hostile "Rich Execution Environment" (the AP running XNU) and how it persists sensitive state.

2.2.1 The Mailbox Interface: Analyzing the IPC Transport

Communication between the Application Processor (AP) and the SEP is strictly asynchronous and interrupt-driven. Unlike the tight coupling of the SPTM (which uses synchronous instruction traps), the SEP interaction is mediated by a hardware mechanism known as the Mailbox, which relies on the proprietary Apple Interrupt Controller (AIC) to manage signaling.

The Physical Transport: Registers and Shared Memory
There is no shared virtual memory space; the two processors exchange messages via a combination of Memory-Mapped I/O (MMIO) registers and physical memory buffers.

The Control Mailbox (MMIO):
The primary control channel consists of dedicated hardware registers within the SEP's configuration space (typically mapped at sep@DA00000 on A-series, with evolving offsets on M-series).
- Inbox/Outbox: The AP writes a message to the Inbox register, which triggers an IRQ on the SEP. The SEP writes a reply to the Outbox register, which triggers an IRQ on the AP.
- M-Series Evolution: On Apple Silicon (M1+), reverse engineering of the apple-mailbox driver indicates a shift toward using shared memory ring buffers for the control path to handle higher throughput, managed by the AIC's hardware event lines.
The Doorbell (Apple Interrupt Controller):
To signal a message, the sender must trigger an exception on the receiver.
- AP → SEP: The kernel writes to a specific AIC "Set" register. This asserts a hardware IRQ line wired to the SEP's core.
- SEP → AP: When the SEP replies, it asserts an IRQ line routed to the AP's AIC. The kernel's interrupt handler (within AppleSEPDriver) acknowledges this by writing to the AIC "Clear" register.

The L4 IPC Protocol:
The data payload passed through the control registers follows a strict, serialized format (often referred to as the SEP Message format). Analysis of the AppleA7IOP / AppleSEPManager stack reveals a compact 64-bit structure:

struct sep_msg {
    uint8_t endpoint;  // Destination service (e.g., 0x10)
    uint8_t tag;       // Transaction ID for async correlation
    uint8_t opcode;    // Message type / Command
    uint8_t param;     // Immediate parameter
    uint32_t data;     // Payload or pointer to OOL buffer
};

Endpoint ID: Routes the message to a specific task within sepOS (e.g., the Secure Key Store).
Out-of-Line (OOL) Buffers: For payloads larger than 32 bits (such as biometric templates or firmware updates), the data field contains a physical address. The AP allocates a physical page, pins it, and passes the address to the SEP. The SEP maps this page into its address space using its own IOMMU (often implemented via DART on M-series chips).

RE Focus: Fuzzing the Boundary
The mailbox is the primary attack surface for the SEP. Vulnerabilities here (parsing malformed messages) can lead to code execution within the Enclave.

Endpoint Fuzzing: The sepOS kernel dispatches messages to user-mode L4 tasks based on the Endpoint ID. Fuzzing specific endpoints (especially legacy or debug endpoints left enabled in production) is a standard methodology.
Shared Memory Hazards (TOCTOU): While the mailbox registers handle control flow, bulk data is passed via shared memory. A classic attack vector involves the AP modifying the data in the shared buffer after the SEP has validated the header/signature but before it processes the body (Time-of-Check to Time-of-Use).

2.2.2 The Secure Storage Component (xART): Encrypted Persistent Storage

The SEP has no general-purpose NAND flash of its own. It must rely on the Application Processor’s storage stack to persist long-lived secrets (passcode state, biometric templates, token material). However, it cannot trust the AP or its filesystem to store this data without tampering.

To solve this, Apple pairs the SEP with a Secure Storage Component, often referred to in firmware and kexts as xART (eXtended Anti-Replay Technology).

At a high level, xART behaves as a dedicated, tamper-resistant non-volatile store that is logically attached exclusively to the SEP:

It has its own non-volatile memory and cryptographic logic.
It is only addressable from within the SEP’s trust domain over a dedicated, authenticated channel.
The AP and XNU have no direct protocol to read or write its contents; all access is mediated by sepOS.

You can think of xART as a small, secure NVRAM bank whose sole purpose is to hold anti-replay metadata and counters that anchor SEP-managed state.

The Architecture:

Physical / Logical Separation:
- At the implementation level, the Secure Storage Component may be a discrete die or a dedicated block within a larger package, but architecturally it presents as a separate secure store accessed only by the SEP.
- The AP sees none of its registers or address space; there are no MMIO ranges that the kernel can map to talk directly to xART.
SEP-Centric View of Storage:
- The SEP treats AP-managed NAND (the main SSD / NVMe) as an untrusted block device.
- All SEP data structures stored there (keybags, counters, templates, tickets) are encrypted and authenticated using keys derived from the UID/GID and xART’s state.
- The xART component holds the small, high-value bits: monotonic counters, per-volume or per-domain nonces, and commitment hashes for larger encrypted blobs stored on the AP’s filesystem.

The Anti-Replay Guarantee:

When the SEP writes persistent state—for example, updating the failed passcode attempt counter or credential state—it performs a two-phase commit:

Write to Untrusted Storage (AP):
- The SEP encrypts the payload (e.g., a keybag or metadata record) with keys derived from the UID and appropriate class keys.
- It sends the ciphertext to the AP via the mailbox protocol.
- The AP writes this to its filesystem (e.g., a file under /private/var/db/), but the contents are opaque to it.
Commit to xART (Secure Storage Component):
- In parallel, the SEP computes a cryptographic digest (e.g., a hash or MAC) over the new payload and the associated monotonic counter or nonce.
- It writes this digest and the updated counter/nonce to xART.
- xART becomes the authoritative record of “what the latest version of this object should look like” and “how many times it has been updated.”

On subsequent reads:

The SEP requests the ciphertext from the AP.
It recomputes the digest and compares it against the value stored in xART for that object.
If the digests and counters match, the SEP accepts and decrypts the payload.
If the AP has replayed an old copy (e.g., with a lower counter or different hash), the mismatch is detected and the SEP treats it as an anti-replay violation—typically halting access to that data or, in severe cases, triggering a lockout.

Security Properties:

Monotonicity:
The SEP’s view of sensitive state (e.g., passcode retry counters, escrow records) is strictly monotonic. An attacker cannot reset or roll back these counters by snapshotting and restoring AP-visible storage, because xART’s internal counters would not match.
AP Transparency:
From the AP’s perspective, xART is a black box. It sees only that some SEP operation failed or succeeded; it never observes the internal counters, keys, or hashes that xART maintains.
Data Binding:
SEP-managed data is effectively bound to:
- The specific SEP instance (via UID).
- The xART anti-replay state (counters / nonces).
- The software measurement (for SKP-like mechanisms described later).

RE Implication:

For reverse engineering, the important consequences are:

Dumping or modifying the files that back SEP state on the AP is insufficient to reset security-sensitive conditions (e.g., passcode retry counters, keybag versions). Without aligning xART’s internal state, any replay will be detected and rejected.
There is no direct AP-visible interface to xART; all interesting protocol surface is in:
- sepOS endpoint handlers that manipulate anti-replay state.
- The AppleSEPKeyStore and related kexts and daemons that proxy higher-level requests (FileVault, Keychain, biometric state) into SEP commands.
Exploits that attempt to tamper with SEP persistence must target:
- The integrity of SEP’s logic around xART updates, or
- The boundary between SEP and AP (e.g., TOCTOU races on the untrusted ciphertext), not the xART hardware itself.

2.2.3 RE Focus: Reverse Engineering the `sepOS` L4 Syscall Table

For the advanced reverse engineer, the holy grail is understanding the sepOS kernel itself. Since it is based on L4, it relies heavily on synchronous IPC for system calls.

Identifying the Syscall Handler:
In the disassembled sepOS binary (decrypted via Boot ROM exploit), the exception vector table is the starting point. The SVC (Supervisor Call) handler dispatches requests based on the immediate value or a register (typically x0 or x8).

Mapping the Tasks:
The sepOS is modular, consisting of the kernel and several user-mode "apps" or "tasks." Analysis of firmware dumps reveals the internal naming convention:

SEPOS: The root task and kernel.
sks (Secure Key Store): The backend for AppleSEPKeyStore, managing Data Protection and Keychain items.
sbio-sd (Secure Biometric Sensor Driver): The backend for biometrickitd, handling the processing of fingerprint and face data.
sse (Secure Element): Manages communication with the NFC Secure Element for Apple Pay.
sepServices: A directory service mapping symbolic names to endpoints.

By tracing the IPC messages dispatched from the Mailbox handler, you can map which L4 task handles which service. For example, messages routed to the endpoint associated with sbio-sd will contain the proprietary command structures for biometric enrollment and matching. Analyzing the message parsing logic within that specific task reveals the attack surface for biometric bypasses.

Tooling Note: Standard tools like IDA Pro or Ghidra require custom loaders for sepOS binaries. The memory layout is non-standard, and the binary format (Mach-O) often has stripped headers or non-standard segment protections that must be manually reconstructed based on the SCIP configuration found in the Boot Monitor logic.

3.0 The Chain of Trust: Firmware & Bootloaders

With the hardware root of trust established and the Secure Enclave operating as a parallel authority, the Application Processor begins the process of bootstrapping the mutable software stack. This phase is governed by the Image4 serialization format and a strict chain of cryptographic handover.

3.1 Low-Level Bootloader (LLB)

On platforms that implement an LLB stage (e.g., Apple Silicon Macs and older A-series SoCs), the Low-Level Bootloader (LLB) is the first piece of mutable code executed by the Application Processor. Loaded by the Boot ROM from the boot partition of the internal flash (NAND, or NOR SPI on some development hardware), it executes initially out of on-die SRAM before DRAM has been brought online. Its primary directive is architectural: it must bridge the gap between the raw silicon state and the feature-rich environment required by iBoot.

3.1.1 Parsing the Image4 (`img4`) Container

To the reverse engineer, "firmware" on Apple Silicon is synonymous with Image4. LLB is not a raw binary; it is encapsulated in an Image4 container, a format based on ASN.1 (Abstract Syntax Notation One) and DER (Distinguished Encoding Rules). Understanding this structure is prerequisite to any firmware analysis.

A complete Image4 object consists of an IM4P (Payload) and an IM4M (Manifest), with an optional IM4R (Restore Info) object used in restore flows.

IM4P (Payload): The actual executable code (the LLB binary).
- Encryption: The payload is encrypted under a per-image AES key. On production devices, this per-image key is wrapped using the SoC’s GID Key and stored in the Keybag (KBAG) tag within the payload. At boot, the hardware AES engine unwraps the KBAG under the GID key to recover the IV and payload key, then decrypts the payload. This means the payload is opaque to external analysis unless decrypted on-device (or via a GID oracle).
- Compression: Once decrypted, the payload is typically compressed (LZSS or LZFSE).
- Type Tag: A 4-character code (e.g., ibot, illb) identifying the component.
IM4M (Manifest): The signature and constraints, commonly known as the ApTicket.
- The Signature: An RSA or ECDSA signature over the SHA-384 hash of the payload.
- The Body: A set of entitlements and constraints (tags) that dictate where and how this payload can run.
- Certificate Chain: The manifest includes the certificate chain leading back to the Apple Root CA. The Boot ROM holds the corresponding root public key (or its hash) in immutable hardware and verifies the chain using the Public Key Accelerator (PKA).
IM4R (Restore Info): (Optional) Contains hardware-specific personalization data used during the restore process, such as the unique nonce generated by the SEP.

The Validation Logic:
When the Boot ROM loads LLB (and when LLB subsequently loads iBoot), it performs the following image4_validate routine:

Parse the ASN.1 structure to separate IM4M and IM4P.
Hash the IM4P (ciphertext).
Locate the corresponding hash in the IM4M (under the specific tag, e.g., illb).
Verify the IM4M signature using the PKA.
If valid, the hardware unwraps the payload key from the KBAG using the GID Key, loads it into the AES engine, and decrypts the IM4P ciphertext.

3.1.2 DRAM Training and Memory Controller Configuration

Before external LPDDR4X/LPDDR5 Unified Memory can be used, the memory controller and PHY must be trained. Early boot code (Boot ROM and/or LLB) runs initially from on-die SRAM until DRAM training has converged. The physical characteristics of RAM—signal timing, voltage margins, and skew—vary slightly between every physical device due to manufacturing tolerances.

The Training Sequence:

Reading SPD/Calibration Data: The boot code reads calibration data from the device tree or dedicated EEPROM areas.
PHY Configuration: It configures the Physical Layer (PHY) interface of the memory controller.
Training Loop: The code executes a complex algorithm that writes patterns to DRAM and reads them back, adjusting delay lines (DLLs) and drive strengths until the signal is stable.
Remapping: Once training is complete, the MCU is brought online. The Memory Management Unit (MMU) is then reconfigured to map the vast expanse of DRAM into the address space.

RE Implication:
If you are attempting to exploit the Boot ROM or early LLB, you are constrained to SRAM. You cannot load large payloads or use heap spraying techniques that require gigabytes of memory until after the bootloader has successfully trained the DRAM. This creates a "choke point" for early-boot exploits.

3.1.3 Verifying the Exclusive Chip ID (ECID) and Board ID

Apple utilizes a mechanism called Personalization (or Taming) to prevent firmware replay attacks. You cannot simply take a valid, signed LLB from one iPhone and run it on another, nor can you downgrade to an older, vulnerable LLB version.

This enforcement happens inside the Image4 parser logic within LLB (checking the next stage) and the Boot ROM (checking LLB).

The Constraint Tags:
The IM4M manifest contains specific tags that bind the signature to the hardware:

ECID (Exclusive Chip ID): A unique per-SoC identifier fused into the chip and exposed as an integer value used for personalization.
BORD (Board ID): Identifies the PCB model (e.g., 0x10 for a specific iPhone logic board).
CHIP (Chip ID): Identifies the SoC model (e.g., 0x8103 for M1).
SDOM (Security Domain): 0x1 for Production, 0x0 for Development.

The Check:
During boot, the executing code reads the actual values from the hardware fuses and compares them against the values present in the signed IM4M.

If Hardware.ECID != Manifest.ECID, the boot halts.
If Hardware.BORD != Manifest.BORD, the boot halts.

This mechanism, combined with the Nonce (a random value generated by the SEP during updates and baked into the IM4M), ensures that the firmware is:

Authentic: Signed by Apple.
Targeted: Valid only for this specific device.
Fresh: Valid only for this specific boot/update cycle (preventing downgrades).

Note: In the "Tahoe" architecture, reverse engineering suggests this verification logic appears to use redundant checks and bitwise operations that resist simple instruction skipping (e.g., glitching a B.NE instruction).

3.2 iBoot (Stage 2 Bootloader)

Once LLB has initialized the DRAM and verified the next stage, it hands off execution to iBoot. While LLB is a hardware-focused shim, iBoot is a sophisticated, compact operating system in its own right. It features a cooperative task scheduler (rather than a simple single-threaded loop) that manages concurrent subsystems including a full USB stack, a display driver (for the Apple logo), and a filesystem driver (APFS/HFS+). In the Tahoe architecture, iBoot’s role has expanded beyond merely bootstrapping the XNU kernel; it now serves as the orchestrator of the platform's security domains, responsible for loading and isolating the hardware-enforced monitors before the kernel is permitted to execute.

3.2.1 The Apple Device Tree (ADT)

The hardware configuration of an Apple Silicon device is not discoverable via standard buses like PCI enumeration alone. Instead, iBoot relies on the Apple Device Tree (ADT)—a hierarchical binary data structure (conceptually similar to OpenFirmware or Linux Device Trees) that describes the SoC's topology.

The Source:
The raw ADT is either embedded within the iBoot binary or loaded as a separate devicetree.img4 payload. It contains nodes describing CPUs, memory maps, interrupt controllers (AIC), and peripherals. Unlike Linux systems which often use a "Flattened Device Tree" (FDT), Apple utilizes its own proprietary binary format for the ADT, which XNU consumes directly via the SecureDTLookup APIs.

Runtime Population (/chosen):
Before jumping to the kernel, iBoot populates the /chosen node of the ADT with critical runtime parameters.

kaslr-seed: A high-entropy random value (inferred to be derived from the TRNG). The kernel uses this to randomize its memory slide.
memory-map: A critical array of structures defining physical memory regions. iBoot marks regions used by the Boot ROM, LLB, and itself as reserved, ensuring the kernel does not overwrite them.
boot-args: The command-line arguments passed to the kernel (e.g., debug=0x14e, -v). On production devices, these are strictly filtered based on the sip3 flags in LocalPolicy; only specific flags are allowed unless the device is in a specific research or demoted state.

3.2.2 New in Tahoe: Loading the Security Monitors

In pre-Tahoe architectures (iOS 14 / macOS 11), iBoot would simply load the kernelcache and jump to it. In the Tahoe era (A15/M2+), iBoot must construct the Guarded Execution Environment before the kernel can exist.

Allocation and Reservation:
iBoot parses the device tree to identify physical memory ranges reserved for the new monitors. It carves these out of the available DRAM:

SPTM Region: Reserved for the Secure Page Table Monitor.
TXM Region: Reserved for the Trusted Execution Monitor.

Payload Loading:
iBoot locates the specific Image4 payloads, which are co-packaged with the kernelcache (referenced in the OS firmware manifest):

Ap,SecurePageTableMonitor: The GL2 binary.
Ap,TrustedExecutionMonitor: The GL1 binary.

It decrypts and verifies these payloads just like any other firmware component. However, instead of loading them into standard memory, it loads them into the reserved physical regions identified above.

Locking SPRR Regions (Conceptual View):
This is the critical security pivot. Before handing off control, iBoot establishes the initial Shadow Permission Remapping Registers (SPRR) state to enforce isolation. While the SPTM performs its own fine-grained configuration upon initialization, the architectural guarantee provided by iBoot is:

The GL2 (SPTM) view is configured to have Read/Write/Execute access to its own memory region.
The GL1 (TXM) view is configured to have access to its region.
Crucially, the GL0 (Kernel) view is configured to mark the SPTM and TXM regions as Inaccessible (No-Access).

This ensures that when the processor eventually drops to EL1 (GL0) to run XNU, the kernel is physically incapable of reading or modifying the monitor code, even though it resides in the same physical DRAM.

3.2.3 LocalPolicy & BAA: The Shift to Local Signing

For macOS, Apple introduced a mechanism to allow users to boot older OS versions or custom kernels (Permissive Security) without breaking the hardware chain of trust. This is managed via LocalPolicy.

The Problem:
The Boot ROM and LLB enforce strict signature checks using manifests issued by Apple's global signing server (TSS). These checks are performed offline using embedded root keys. If you want to boot a custom kernel, you cannot obtain a valid signature from Apple's TSS.

The Solution:

LocalPolicy: A policy file stored on the Data Volume (in the iSCPreboot volume). It specifies the security mode (Full, Reduced, Permissive) and the hash of the custom kernel collection.
Owner Identity Key (OIK): When a user authorizes a downgrade or custom boot (via Recovery Mode authentication), they are effectively authorizing the use of a device-specific Owner Identity Key (OIK) generated within the Secure Enclave. This key is certified once by Apple's Basic Attestation Authority (BAA).
Re-Signing: The LocalPolicy is signed by the SEP using this OIK.
Boot Time: iBoot fetches the LocalPolicy. It asks the SEP to verify the signature against the OIK. If the SEP confirms the policy is valid (and matches the user's intent), iBoot proceeds to load the custom kernel hash specified in the policy (enabled via the smb1 bit), effectively "blessing" it for this boot cycle.

This allows "Permissive Security" to exist while keeping the Boot ROM and LLB strictly locked down to the hardware root of trust.

3.2.4 RE Focus: Decrypting iBoot Payloads via the AES MMIO Interface

To analyze iBoot, one must decrypt it. Since the GID key is fused into the silicon and physically disconnected from the CPU's register file, it cannot be extracted via software. Reverse engineers must instead turn the device into a Decryption Oracle by manipulating the dedicated AES hardware peripheral.

The kbag Mechanism:
The Image4 payload (IM4P) is encrypted with a random, per-file symmetric key (the target key). This target key is wrapped (encrypted) with the GID key and stored in the IM4P header as a Keybag (kbag). To decrypt the firmware, one must unwrap this kbag.

The Hardware Distinction (ISA vs. MMIO):
It is critical to distinguish between the ARMv8 Crypto Extensions (instructions like AESE, AESD) and the Apple AES Peripheral.

ARMv8 Crypto: Operates on keys loaded into standard NEON/SIMD registers (v0-v31). Useful for TLS or disk encryption where the key is known to the OS.
Apple AES Peripheral: A memory-mapped I/O (MMIO) block, typically located at a base offset like 0x23D2C0000 (on M1/T8103) or similar 0x2... ranges on newer SoCs. This peripheral has exclusive hardware access to the GID key fuses.

The Oracle Exploit:
Using a Boot ROM exploit (like checkm8 on A-series) or a specialized iBoot exploit, researchers execute a payload that drives this MMIO interface directly:

Reset: Reset the AES peripheral via the AES_CTRL register to clear internal state.
Key Selection: Write to the configuration register to select the GID Key as the decryption source. This sets an internal mux; the key itself is never exposed to the bus.
FIFO Loading: Write the kbag (IV + Ciphertext) into the AES_DATA_IN FIFO registers.
Execution: Trigger the engine. The hardware pulls the GID key from the fuses, performs the AES-256-CBC unwrap, and pushes the result to the output buffer.
Extraction: Read the unwrapped target key (typically formatted as iv:key) from the AES_DATA_OUT register.

Hypothesized Countermeasures:
Modern Apple Silicon (A12+/M1+) implements countermeasures against this oracle usage. Reverse engineering suggests the AES engine may enforce a state machine that requires the output of a GID decryption to be immediately DMA'd to executable memory and jumped to, rather than read back into a general-purpose register. Bypassing this theoretically requires Fault Injection (voltage glitching) to corrupt the state machine or precise timing attacks to race the hardware's "sanitize on read" logic, allowing the extraction of the plaintext key before the hardware scrubs it.

4.0 The Security Monitor Layer (GL1/GL2): The Exclave Architecture

In the "Tahoe" architecture, the XNU kernel has been demoted. It no longer possesses the ultimate authority to define the virtual memory layout of the system. That power has been migrated to a hardware-enforced monitor running in a proprietary execution state known as the Secure World (specifically, the Guarded Execution Feature or GXF). This section dissects the mechanics of this new layer, which effectively functions as a silicon-enforced hypervisor for the kernel itself.

4.1 The Secure Page Table Monitor (SPTM) - GL2

The Secure Page Table Monitor (SPTM) operates at Guarded Level 2 (GL2). It is the highest privilege runtime component on the Application Processor, sitting above both the XNU Kernel (EL2) and the Secure Kernel (GL1). The SPTM is the sole entity permitted to write to the physical pages that constitute the translation tables (TTBR0/TTBR1) for the managed domains of both the Normal and Secure worlds.

4.1.1 The `GENTER` and `GEXIT` Instructions: Context Switching

Transitions into the SPTM utilize the proprietary GENTER instruction, which performs a synchronous, atomic context switch.

The GENTER ABI:
To invoke the SPTM, the kernel populates specific registers and executes the opcode.

Opcode: 0x00201420 (Little Endian).
x16 (Dispatch Target): The primary control register. It holds the sptm_dispatch_target_t, a 64-bit value encoding the Domain (e.g., XNU, TXM, SK), the Dispatch Table ID, and the Endpoint ID (function index).
x0 - x7 (Arguments): The parameters for the call (e.g., physical addresses, permission flags). x0 is often reserved for the thread stack pointer when relaying calls to the TXM.
Immediate Value: The 5-bit immediate encoded in the GENTER instruction itself serves as an entry index, selecting the specific GXF entry stub (recorded in ESR_GLx).

The Hardware Transition:
Upon execution of GENTER:

World Switch: The hardware traps to GL2.
SPRR Switch: The hardware swaps the active Shadow Permission Remapping Register configuration. The memory regions containing the SPTM code and data—previously invisible to the kernel—become Read/Write/Execute.
Stack Switch: The Stack Pointer (SP) is switched to the SP_GL2 register, pointing to a dedicated secure stack within the SPTM's private memory.
PC Jump: Execution jumps to the vector defined in GXF_ENTRY_EL2 (or equivalent GL2 vector base).

The Return:
The SPTM returns control to the kernel using GEXIT (0x00201400). This restores the EL2 SPRR configuration and the kernel's stack pointer. Crucially, on the return path, the SPTM and TXM scrub their per-thread state and shared buffers before executing GEXIT, ensuring that sensitive GL-only data is not left in registers or shared pages exposed to the kernel.

4.1.2 The Frame Table (FTE): Tracking Physical Reality

To enforce security, the SPTM cannot rely on the kernel's data structures (like vm_page_t), as they are mutable by a compromised kernel. Instead, the SPTM maintains its own "God View" of physical memory called the Frame Table.

The Frame Table is a linear array of Frame Table Entries (FTE), located in SPTM-private memory. There is one FTE for every 16KB page of physical RAM (matching the kernel's translation granule).

FTE Structure and Domains:
The FTE tracks the state of every physical page, enforcing strict ownership by SPTM Domains (sptm_domain_t). While the internal enum values evolve, the conceptual types include:

XNU_DATA (XNU Domain): Generic kernel heap/stack.
XNU_TEXT (XNU Domain): Immutable kernel code.
PAGE_TABLE (SPTM Domain): A page containing translation entries (TTEs).
EXCLAVE_DATA (SK Domain): Memory owned by the Secure World.
SPTM_PRIVATE (SPTM Domain): Internal monitor structures.

The Security Invariant:
The SPTM enforces that a physical page can only be mapped into a virtual address space if the mapping permissions are compatible with the page's Type and Domain. For example, a page marked XNU_DATA cannot be mapped as Executable. A page marked PAGE_TABLE cannot be mapped as Writable by the kernel.

4.1.3 The Dispatch Table: Reverse Engineering the Selectors

The interface between XNU and the SPTM is a strict, register-based API. However, unlike the stable syscall numbers of the BSD layer, the SPTM Dispatch IDs are not guaranteed to remain static across macOS versions. Apple frequently rotates these IDs to frustrate static analysis tools.

The ABI:

x16: The sptm_dispatch_target_t (Domain + Table + Endpoint).
x0 - x7: Arguments (Physical Addresses, Permission Bitmasks, ASIDs).

Heuristic Identification:
Since relying on static IDs is brittle, reverse engineers must fingerprint the logic of the handler functions within the Ap,SecurePageTableMonitor binary to identify the primitives.

sptm_retype(ppn, old_type, new_type):
- Fingerprint: Look for a function that accepts a Physical Page Number (PPN), reads the corresponding Frame Table Entry (FTE), and performs a Sanitization Loop. The SPTM must zero-fill (bzero) or cache-invalidate the page before transitioning it from XNU_DATA to PAGE_TABLE to prevent the kernel from initializing a page table with pre-computed malicious entries.
- Logic: assert(refcount == 0); memset(pa, 0, PAGE_SIZE); fte->type = new_type;
sptm_map(asid, va, ppn, perms):
- Fingerprint: Look for a function that walks the translation tables (reading physical memory) and performs a Permission Check against the FTE. It will contain logic that explicitly compares the requested perms (e.g., Write) against the fte->type (e.g., XNU_TEXT).
- Logic: if (fte->type == XNU_TEXT && (perms & WRITE)) panic(); write_tte(...);
sptm_unmap(asid, va):
- Fingerprint: Look for the TLB Invalidation sequence. For SPTM-controlled mappings, TLB invalidation is performed inside GL2 as part of the unmap routine. XNU cannot directly update those page tables and must invoke SPTM to perform any changes, including the corresponding TLB maintenance (TLBI ALLE2IS or similar).
sptm_map_iommu(dart_id, context_id, dva, ppn, perms):
- Fingerprint: Look for writes to MMIO regions associated with DART controllers, rather than standard RAM. This function validates that the ppn is not a protected kernel page before mapping it into a device's IOVA space.

RE Implication:
Automated analysis scripts should not rely on CMP x15, #0x1. Instead, they should symbolically execute the GENTER handler in the SPTM binary, identifying the dispatch table jump via x16, and then classify the target functions based on the presence of DC ZVA (cache zero), TLBI, or FTE array access patterns.

4.1.4 RE Focus: Analyzing Panic Strings and the State Machine

The SPTM is designed to be Fail-Secure. Unlike standard kernel APIs that return KERN_FAILURE, the SPTM treats invalid requests as evidence of kernel compromise.

The Panic Mechanism:
If XNU sends a malformed request (e.g., trying to retype a page that is still mapped), the SPTM treats this as a fatal security violation. Instead of returning an error code that a compromised XNU could potentially suppress, the SPTM directly initiates the system panic or halt sequence.

Panic String: "received fatal error for a selector from TXM" or "invalid state transition".
Analysis: These strings are gold for reverse engineers. They confirm that the SPTM enforces a strict Finite State Machine (FSM) for memory pages.

Mapping the State Machine:
By analyzing the panic logic and the allowed transition bitmaps, we can deduce the allowed transitions:

FREE → XNU_DATA (Allocation)
XNU_DATA → PAGE_TABLE (Retype for MMU use - requires sanitization)
PAGE_TABLE → XNU_DATA (Teardown - requires unmapping all entries)
XNU_DATA → XNU_TEXT (KEXT loading - One-way transition!)

Any attempt to deviate from this graph (e.g., trying to turn PAGE_TABLE directly into XNU_TEXT) results in an immediate halt. This prevents "Page Table Spraying" and other heap manipulation techniques used to gain kernel execution.

4.2 The Trusted Execution Monitor (TXM) – GL0

If the SPTM is the brawn—enforcing the physics of memory mapping—the Trusted Execution Monitor (TXM) is the brains. Operating as a privileged Conclave at Guarded Level 0 (GL0), the TXM is the supreme arbiter of system policy. It represents the architectural decoupling of “mechanism” from “policy.” While the SPTM handles how a page is mapped, the TXM decides if it is allowed to be mapped executable under a given policy.

4.2.1 Decoupling AMFI: Moving Core Code-Signature Verification

Historically, the Apple Mobile File Integrity (AMFI) kernel extension was the primary enforcement point for code signing. While AMFI still exists to handle complex userland policy checks, in the Tahoe architecture the core cryptographic verification logic for platform and protected code has been lifted out of the kernel and placed into the TXM. TXM’s primary currency of trust is the Code Directory Hash (CDHash).

The Verification Flow (conceptual):

Load & Hash: The kernel (XNU) loads a binary into memory (typed as XNU_DATA). It parses the LC_CODE_SIGNATURE load command and calculates the CDHash (typically SHA-256 over the Code Directory).
The Query: XNU issues a call into the Secure World. The Secure Kernel (GL1) routes this to the TXM (GL0). The kernel passes the CDHash and the physical address range that will back the executable mapping.
Trust Cache Lookup: The TXM consults its internal Trust Caches:
- Static Trust Cache: CDHashes for immutable OS binaries (kernel collections, dyld shared cache, system daemons shipped in Cryptexes).
- Loadable / Dynamic Trust Caches: CDHashes for binaries that have been verified previously (third-party apps, JIT regions, auxiliary trust caches).
Cold Validation: On a cache miss, the system enters a “cold path”. The kernel, often assisted by amfid and syspolicyd, provides the CMS signature blob and certificate chain for the image. TXM performs the cryptographic verification against the relevant Apple root (or Developer ID root) inside the guarded world. On success, the CDHash is inserted into an appropriate trust cache.
Blessing: Once the CDHash is validated according to platform policy, TXM updates its internal state so that the specific physical pages associated with that CDHash are marked as “permitted for execution” when requested with appropriate permissions.
Enforcement via SPTM: When XNU later asks the SPTM to map those pages as Executable (RX), the SPTM consults TXM (or the trust-cache state driven by TXM). If the pages are not in a state that policy allows to become executable, the SPTM denies the Execute permission, even if EL2 code tries to set it in the PTE.

Platform distinction (iOS-class vs macOS):

The exact policy enforced by TXM/SPTM is platform-dependent:

On iOS / iPadOS / watchOS / visionOS, TXM + SPTM implement a hard invariant: only code that is both correctly signed and policy-approved is allowed to become executable. AMFI’s view of “signed or not” is no longer sufficient on its own; the SPTM must agree.
On macOS, the platform is explicitly designed to allow arbitrary and ad-hoc user code to run. In that environment:
- TXM still verifies and tracks platform binaries (kernel collections, system frameworks, hardened system daemons) and other code that participates in the system integrity story (e.g. components running with special entitlements or under hardened runtime).
- SPTM still mediates executable mappings and protects the integrity of page tables and immutable kernel/monitor regions.
- However, the global “no unsigned code ever executes” property is not applied to general userland on macOS. The set of mappings that SPTM/TXM treat as “must be verified” is narrower and aligned with Apple’s documented policy distinction between macOS and fully locked-down platforms.

RE Implication:

On iOS-class platforms, patching the kernel to ignore AMFI errors is no longer a sufficient route to arbitrary unsigned code execution: the SPTM/TXM stack must still bless the mapping. Attempts to create executable mappings for code that TXM has not accepted will fail at the SPTM boundary.
On macOS, a kernel compromise can still influence which user binaries run (for example, by weakening or bypassing Gatekeeper and AMFI checks for user processes), and ad-hoc binaries remain architecturally admissible. The SPTM/TXM stack primarily constrains:
- the integrity of page tables and KIP/KTRR-like regions,
- the mappings of kernel collections and other protected code, and
- the ability of a compromised kernel to subvert those invariants.

In all cases, SPTM continues to arbitrate frame typing and protected mappings above EL2. TXM’s policy decisions define which code is eligible for protection and execution under a given mode; SPTM enforces the resulting invariants in the page-table and DART hardware.

4.2.2 The Trust Cache: Static vs. Loadable

To avoid the performance penalty of cryptographic verification on every page fault, the TXM manages the Trust Cache—a database of known-good CDHashes.

The Static Trust Cache:
This is loaded by iBoot and passed to the TXM during the Secure World initialization. It contains the hashes of every binary in the OS (now encapsulated in the immutable Cryptexes). This cache resides in Secure World memory and is strictly Read-Only.
Loadable Trust Caches:
These handle third-party applications, JIT regions, and auxiliary updates. When a user launches an app, the TXM verifies the signature once and adds the CDHash to a loadable cache.
- Query Interface: The kernel queries the Trust Cache via a specific GENTER selector.
- Attack Surface: These caches are mutable structures managed by the TXM. A logic bug in the TXM's management of this cache (e.g., a race condition during entry removal or a hash collision attack) is a high-value target for persistence.

4.2.3 Developer Mode Enforcement and Downgrade Protection

The TXM is also the guardian of the device's security posture, specifically Developer Mode.

In previous iterations, enabling debugging capabilities was often a matter of setting nvram variables or boot-args (like cs_enforcement_disable=1). In Tahoe, these states are managed by the TXM.

The State Transition:
Enabling Developer Mode requires a reboot and explicit user authorization (Secure Intent via physical buttons). The TXM persists this state (likely via the Secure Enclave's secure storage).

Downgrade Protection:
The TXM enforces that the system cannot transition from a "Production" state to a "Developer" state without a full reboot and authentication ceremony. This prevents a kernel-level attacker from dynamically relaxing security policies to load unsigned modules.

Furthermore, the LocalPolicy (signed by the SEP) encodes whether the system is in Full, Reduced, or Permissive Security. Early-boot components (LLB/iBoot) will refuse to start macOS without a valid LocalPolicy, preventing silent downgrades of security policy. At runtime, the TXM consults this configuration when deciding which code-signing and trust-cache policies to enforce.

5.0 XNU Kernel Initialization: Entering GL1

The handoff from iBoot to the XNU kernel marks the transition from a single-threaded bootloader to a symmetric multiprocessing (SMP) operating system. However, in the Tahoe architecture, this is no longer a handover of absolute power. In the Tahoe architecture on M4 silicon, the XNU kernel executes at Guarded Level 1 (GL1) (Hardware EL1), while the Secure Page Table Monitor (SPTM) occupies Guarded Level 2 (GL2) (Hardware EL2). Consequently, the kernel enters not as a master, but as a guest under the SPTM's supervision.

The entry point is defined in osfmk/arm64/start.s. At this precise moment, the system state is fragile: the MMU is operating under a minimal bootstrap mapping provided by iBoot (or disabled entirely depending on the specific SoC generation), interrupts are masked (DAIF bits set), and the stack pointer is essentially arbitrary. The kernel's first objective is to orient itself within physical memory, calculate the KASLR slide, and establish the virtual memory structures required to turn on the lights.

5.1 The `start` routine and KASLR

The _start symbol is the architectural entry point. Unlike x86_64, where the kernel might handle its own decompression and relocation, the Apple Silicon kernel is loaded as a raw Mach-O executable (within the kernelcache container) directly into physical memory by iBoot.

The Register State at Entry:

CurrentEL: Indicates EL2 (on standard macOS Tahoe configurations).
x0: Physical address of the boot_args structure (version 2).
x1: Physical address of the Device Tree base (if not inside boot_args).
x2: 0 (Reserved/Empirically observed).
x3: 0 (Reserved/Empirically observed).
sp: Invalid/Temporary.

5.1.1 Deriving the Kernel Slide: The Decoupled Address Space

Kernel Address Space Layout Randomization (KASLR) on Apple Silicon is a cooperative effort between iBoot and XNU. iBoot generates a high-entropy value from the TRNG, populates the /chosen/kaslr-seed property in the Device Tree, and physically relocates the kernel text in DRAM to match this slide.

The boot_args Structure:
Upon entry at _start, the kernel immediately parses the boot_args structure pointed to by x0. This structure acts as the handover manifest, containing:

virtBase: The runtime virtual base address where the kernel is mapped (i.e., the static base plus the slide).
physBase: The actual physical load address in DRAM.

The Slide Calculation:
The kernel calculates its own slide by comparing the runtime virtual base provided by iBoot against its compile-time static base:

$$ \texttt{vm\_kernel\_slide} = \texttt{boot\_args.virtBase} - \texttt{STATIC\_KERNEL\_BASE} $$

The Tahoe Constraint: Address Space Decoupling:
In the Tahoe architecture, the system operates under a paradigm of Address Space Decoupling. The SPTM (GL2) and the Kernel (EL2) reside in the same physical DRAM but operate in distinct translation regimes.

Kernel View: The kernel runs under TTBR1_EL2 (or TTBR1_EL1 with VHE), with a virtual layout randomized by kaslr-seed.
SPTM View: The SPTM runs under the GL2 translation regime with its own independent set of translation table base registers.

Security Implication:
This separation is critical. A kernel-level memory leak (e.g., an infoleak revealing a kernel pointer) allows an attacker to calculate vm_kernel_slide. In previous architectures, if the monitor (PPL) was mapped at a fixed offset relative to the kernel, a kernel leak would instantly reveal the monitor's location.

In Tahoe, knowing vm_kernel_slide yields zero information about the virtual address of the SPTM. The SPTM's virtual mapping is established by iBoot in the GL2 context before the kernel executes. While the kernel is aware of the SPTM's physical pages (marked as "Reserved" in the memory map), it is architecturally blind to the SPTM's virtual location.

RE Focus: Finding the Slide:
For a reverse engineer with a kernel panic log or a JTAG connection, identifying these slides requires inspecting distinct registers:

Kernel Slide: Inspect TTBR1_EL2 (or TTBR1_EL1 if VHE is active). The translation table base points to the physical location of the kernel's L1 table. The high bits of the PC (Program Counter) at the exception vector reveal the virtual slide.
SPTM Slide: This is invisible from EL2. To find it, one must inspect the GL2-specific TTBRs via JTAG while the core is halted in the GL2 context.
Static Analysis: The vm_kernel_slide global variable in XNU is one of the first initialized. In a raw memory dump, locating the boot_args struct (often at the start of a physical page aligned to 16KB) will reveal the virtBase directly.

5.1.2 Initializing the MMU: `TCR_EL2` and the SPTM Handshake

Before the kernel can execute C code safely, it must enable the Memory Management Unit (MMU). On standard ARMv8, this involves populating translation tables and writing to TTBR0 and TTBR1, then setting SCTLR.M.

On Tahoe, this process is fundamentally altered because the kernel cannot write to its own page tables.

The Bootstrap Problem:
How does the kernel build its initial page tables if it requires the SPTM to map pages, but the SPTM requires the kernel to make hypercalls?

The Solution: The Bootstrap Tables:
iBoot installs a minimal set of Bootstrap Page Tables before handing off control. These tables typically contain identity mappings for the PC and stack, allowing the kernel to execute the initialization code required to bring up the SPTM interface.

TCR_EL2 Setup: The kernel configures the Translation Control Register (TCR_EL2).
- T1SZ / T0SZ: Defines the size of the virtual address space (typically 48-bit on macOS).
- TG1: Granule size (16KB is standard for Apple Silicon).
- IPS: Intermediate Physical Address Size (matches the SoC capability, e.g., 40 bits).
- TBI (Top Byte Ignore): Typically configured to allow the top byte (bits 63-56) to carry metadata (such as PAC signatures or tags) without affecting address translation.

The SPTM Handshake (The First GENTER):
Once TCR_EL2 is configured, the kernel must transition from the iBoot-provided bootstrap tables to its own managed tables.

Allocation: The kernel allocates physical pages for the new L1/L2/L3 translation tables from the XNU_DATA pool.
Sanitization: The kernel zeroes these pages.
Retype: The kernel executes GENTER (Selector 0x01 - sptm_retype) to convert these pages from XNU_DATA to PAGE_TABLE.
Mapping: The kernel executes GENTER (Selector 0x02 - sptm_map) to populate the entries, replicating the kernel text and static data mappings.
Activation: Finally, the kernel programs the appropriate TTBR1 (EL1 or EL2 depending on configuration) to point to the new L1 table. The SPTM constrains the actual effect via SPRR/GXF.

The SCTLR_EL2 Lockdown:
The final step of start is writing to the System Control Register (SCTLR_EL2).

M (MMU Enable): Set to 1.
C (Cache Enable): Set to 1.
WXN (Write-XOR-Execute): Set to 1.

In Tahoe, writes to SCTLR_EL2 are mediated by GL2/SPTM (via GXF’s control over system registers). GL2 enforces that configurations keep WXN set, preventing EL2 from creating writable-executable mappings even if compromised. If the kernel attempts to disable WXN, the SPTM rejects the configuration and panics the device.

Once the MMU is active and the kernel is running on its own page tables (managed by SPTM), the start routine branches to arm_init, beginning the high-level initialization of the BSD subsystem and IOKit.

5.2 Hardware Security Enforcements (The "Kill Switch" Registers)

As the kernel initialization sequence progresses through start, it reaches a critical inflection point. The memory management structures are initialized, and the kernel is about to transition from a setup phase to a runtime phase. To prevent a compromised runtime kernel from modifying its own logic, the initialization routine must engage the hardware "Kill Switches."

In the Tahoe architecture, this protection is layered: KTRR provides the physical baseline, KIP defines the boot-time immutable regions, and the SPTM virtualizes and extends these concepts to enforce dynamic immutability.

5.2.1 KTRR (Kernel Text Read-Only Region): The Physical Lock

Kernel Text Read-Only Region (KTRR) is Apple’s hardware solution to the "W^X" (Write XOR Execute) problem at the physical memory controller level. While the MMU (via page tables) controls virtual access permissions, page tables are mutable data structures. KTRR enforces read-only permissions for a physical range corresponding to kernel text, below the level of page tables. Even if an attacker can mutate PTEs, writes into the KTRR physical region are blocked or faulted.

The Register Interface:
KTRR is controlled via a set of proprietary system registers, typically accessible via MSR instructions.

KTRR_LOWER_EL1 (S3_4_c15_c2_3): Defines the physical start address of the protected range.
KTRR_UPPER_EL1 (S3_4_c15_c2_4): Defines the physical end address.
KTRR_LOCK_EL1 (S3_4_c15_c2_2): The kill switch. Writing 1 to the lock bit enables the protection.

The Tahoe Evolution (Virtualization of KTRR):
On M3/M4 chips running the SPTM, the kernel's interaction with KTRR changes. It is confirmed that the SPTM virtualizes these registers; writes from the kernel trap to the SPTM at EL2, which strictly validates and rejects unauthorized modifications. When XNU executes the legacy instructions to write to KTRR_LOWER/UPPER in start, the hardware traps these accesses. The SPTM validates that the kernel is attempting to cover the correct physical range and enforces its own policy, effectively mocking the success of the operation to the kernel while ensuring the hardware is locked down.

RE Focus: The KTRR Slide Alignment
Because KTRR operates on physical ranges with large granularity (e.g., 1MB or L2 cache line boundaries), the KASLR slide is forced to align to this granularity. If you are brute-forcing the KASLR slide, knowing the KTRR alignment constraint significantly reduces the entropy search space.

5.2.2 Kernel Integrity Protection (KIP) and SPTM Sealing

KTRR protects the static kernel binary (kernelcache). However, modern macOS relies heavily on the Boot Kernel Collection (BKC) and Auxiliary Kernel Collection (AKC)—large caches of drivers and extensions loaded during boot.

Hardware KIP:
Apple documentation refers to Kernel Integrity Protection (KIP) as a hardware feature where the memory controller defines a protected region into which iBoot loads the kernel and kernel extensions, then denies writes after boot. This serves as the static anchor for the BKC.

SPTM Dynamic Sealing (XNU_TEXT):
The SPTM generalizes this concept to support dynamic loading. Unlike static KTRR/KIP regions, the SPTM maintains a Frame Table where pages can be typed.

Registration: During start, the kernel links and relocates extensions.
Sealing: The kernel issues a GENTER call (Selector sptm_retype or sptm_protect) to "seal" the region.
Retyping: The SPTM updates the Frame Table Entries (FTE) for the physical pages backing the drivers, transitioning them from XNU_DATA (Writable) to XNU_TEXT (Executable/Read-Only).

The "One-Way" Door:
The security invariant enforced here is that memory typed as XNU_TEXT is never writable by EL2. If the kernel attempts to write to a sealed page, the SPRR configuration for EL2 triggers a permission fault. This effectively turns the kernel extensions into ROM, mitigating rootkits that historically operated by patching IOKit vtables in memory.

5.2.3 The System Control Register (`SCTLR_EL2`) Lockdown

The final "Kill Switch" is the configuration of the ARM processor itself. The SCTLR_EL2 register controls the MMU, caches, and alignment checks.

Critical Bits:

WXN (Write-XOR-Execute): Bit 19. When set, any memory region mapped as Writable is implicitly treated as Non-Executable (XN).
M (MMU Enable): Bit 0.

The Trap-and-Emulate Policy:
In a standard ARM system, EL2 can modify SCTLR_EL2 at will. In the Tahoe architecture, writes to SCTLR_EL2 are mediated by GL2/SPTM via GXF’s control over system registers. The effective policy under normal operation is that WXN remains set: GL2/SPTM will not accept configurations that clear WXN to create writable–executable regions. If the kernel attempts to program SCTLR_EL2 with WXN cleared, the requested configuration is rejected by the monitor and, in current implementations, this manifests as a system panic rather than a silent relaxation of protections. This ensures that the fundamental security properties of the execution environment (in particular W^X) cannot be disabled, even by a compromised kernel.

5.3 Exclaves: The Microkernel within the Monolith

The introduction of Exclaves in the Tahoe architecture represents the most profound structural change to the Apple OS ecosystem since the transition from Mac OS 9 to OS X. It is an admission that the monolithic kernel architecture (XNU) has become too large, too complex, and too mutable to serve as the ultimate Trusted Computing Base (TCB) for high-value assets.

Exclaves introduce a Microkernel architecture running side-by-side with the monolithic XNU kernel on the same Application Processor cores. Unlike the Secure Enclave (which is a separate coprocessor), Exclaves harness the full performance of the M-series cores while maintaining cryptographic isolation enforced by the SPTM.

5.3.1 The L4 Influence: Domains, Conclaves, and IPC

The architecture of the Exclave system is heavily indebted to the L4 microkernel family. It prioritizes minimalism, capability-based security, and strict isolation.

The Hierarchy of Isolation:

The Secure Kernel (ExclaveOS): A tiny, formally verifiable kernel that manages scheduling and IPC within the secure world. It runs at GL1.
Domains: The highest level of separation. The "Insecure Domain" hosts XNU and userland (EL2/EL0). The "Secure Domain" hosts Exclave workloads.
Conclaves: Within the Secure Domain (GL0), workloads are siloed into Conclaves. A Conclave is a lightweight container consisting of an address space, a set of capabilities (handles to resources), and threads.

Memory Management via SPTM:
The isolation is enforced by the SPTM's Frame Table. Physical pages assigned to an Exclave are typed in the FTE (likely as EXCLAVE_DATA or SK_DATA). The kernel sees these physical pages as "reserved" in the device tree. Any attempt by XNU to map these pages via sptm_map will result in a panic, as the SPTM forbids mapping Exclave-owned pages into the XNU_DOMAIN.

5.3.2 RE Focus: The `RingGate` Mechanism and `XNUProxy`

For the reverse engineer, the critical question is: How does the Kernel talk to an Exclave? They share no virtual memory, run in different hardware contexts, and the SPTM actively prevents XNU from mapping Exclave physical pages. The bridge is a mechanism internally referred to by researchers as RingGate, facilitated by a component named XNUProxy.

The Communication Stack:

Tightbeam (The IDL):
Apple has introduced a new Interface Definition Language (IDL) called Tightbeam. It replaces the legacy Mach Interface Generator (MIG) for secure world communication. Tightbeam is strongly typed and buffer-centric.
- Userland Analysis: The serialization logic is visible in /usr/lib/libTightbeam.dylib.
- Kernel Analysis: XNUProxy appears both as an XNU-side component and as related services in the secure world, bridging Mach ports to Exclave endpoints.
The Downcall (XNU → Exclave):
When XNU needs a service, it cannot call the function directly.
- Marshaling: XNUProxy serializes the request using Tightbeam into a shared memory ring buffer.
- The Gate: The kernel executes a specific instruction to trigger the world switch. This is a GENTER instruction targeting a specific Dispatch ID reserved for the Secure Kernel.
- Context Switch: The hardware (mediated by SPTM) saves the EL2 state, switches the SPRR configuration to the Exclave view, and jumps to the ExclaveOS entry point (GL1).
The Upcall (Exclave → XNU):
Exclaves rely on XNU for file system I/O or networking.
- The Exclave writes a request to the outbound ring buffer.
- It triggers an interrupt or executes a GEXIT yield.
- XNUProxy receives the notification, reads the request, performs the operation via standard VFS calls, and returns the result via a Downcall.

Memory Loaning (The "DART" Window):
While control messages go through ring buffers, large data transfers occur via Memory Loaning. XNUProxy pins a userland page and passes its physical address to the Exclave via Tightbeam. The Exclave requests the SPTM to map this specific PPN into its address space. This "Loaned Memory" mechanism is a prime target for TOCTOU (Time-of-Check to Time-of-Use) attacks, as the ownership transitions are complex and mediated by the SPTM state machine.

5.3.3 Use Case: Secure Control of Privacy Indicators and Passkeys

The "Killer App" for Exclaves in macOS Tahoe is the hardware-enforced privacy indicator (the green/orange dots).

Reverse engineering of current macOS Tahoe builds strongly suggests that these indicators are implemented using an Exclave-controlled overlay path along the following lines:

The Tahoe Solution:

Hardware Ownership: The physical framebuffer region corresponding to the status bar indicators is, in current implementations, not mapped in the XNU domain. It appears to be owned exclusively by a specific Privacy Conclave (GL0), so that only secure-world code can directly address the pixels used for the indicators.
The DART Lock: The Display Coprocessor's IOMMU (DART) is configured under SPTM control such that the main display pipe used by XNU and WindowServer cannot write to the indicator pixels. Only a secure overlay pipe, controlled by the Exclave domain, is allowed to source scanout data for that region.
Immutability: Under this design, XNU cannot map the physical memory backing the secure overlay, and it cannot reconfigure the relevant DART contexts without going through SPTM policy. As a result, a compromised kernel is effectively unable to erase or suppress the indicator once the secure pipeline has decided it should be visible.

Passkeys and FIDO:
Similarly, passkey operations are increasingly implemented inside Exclave-backed services.

Key Isolation: The key material for Passkeys is generated and stored in hardware-isolated domains (SEP plus, on newer platforms, Exclave-backed services), with XNU only ever handling opaque identifiers or tokens rather than raw private keys.
Isolation: Even if malware injects code into the LocalAuthentication daemon or the kernel, it cannot extract the private key material, because it resides in a memory domain that the Normal World cannot directly address.

6.0 The Mach Subsystem: The Nervous System

While the SPTM and Exclaves represent the new fortress walls of the Apple Silicon architecture, the Mach subsystem remains the internal nervous system that coordinates activity within the XNU kernel. Originating from the NeXTSTEP era, Mach provides the fundamental primitives for Inter-Process Communication (IPC), thread scheduling, and virtual memory management.

For the reverse engineer, Mach is the primary vector for local privilege escalation (LPE). Despite decades of hardening, the complexity of state management in Mach messaging remains a fertile ground for logic bugs, race conditions, and reference counting errors. In the Tahoe era, Mach has been retrofitted with heavy PAC enforcement to protect its object graph.

6.1 Mach Ports & IPC Primitives

At the conceptual level, Mach is an object-oriented kernel. The fundamental unit of addressing is the Mach Port. To a userland process, a port is merely a 32-bit integer handle (mach_port_name_t). To the kernel, it is a complex, reference-counted data structure (ipc_port) that acts as a unidirectional communication channel.

6.1.1 Port Rights: Receive, Send, Send-Once, and Dead Names

The security model of Mach is capability-based. Possessing a port name is meaningless without the associated Port Right. The kernel tracks these rights in the process's IPC space.

MACH_PORT_RIGHT_RECEIVE: The ownership right. Only one task can hold the Receive right for a specific port at any given time. This task is the destination for messages sent to the port.
- Kernel Structure: The ipc_port struct contains a pointer (ip_receiver) to the ipc_space of the task holding this right.
MACH_PORT_RIGHT_SEND: The ability to queue messages into the port. Multiple tasks can hold send rights to the same port. This is the standard "client" handle.
MACH_PORT_RIGHT_SEND_ONCE: A "fire-and-forget" right that vanishes after a single message is sent. This is critical for the Request/Reply pattern (RPC). When a client sends a message, it typically includes a MAKE_SEND_ONCE right to its own reply port. The server uses this to send exactly one reply, preventing the server from spamming the client later.
MACH_PORT_RIGHT_DEAD_NAME: If the task holding the Receive right dies or destroys the port, all outstanding Send rights in other tasks are instantly transmuted into Dead Names. Any attempt to send a message to a dead name returns MACH_SEND_INVALID_DEST.

RE Focus: The ipc_port Structure and PAC:
In previous generations, a common exploit technique involved "Fake Ports"—spraying the heap with crafted data that looked like an ipc_port struct and then tricking the kernel into using it.

In the arm64e/Tahoe architecture, the ipc_port structure is heavily fortified:

ip_object: The base header of the port.
ip_kobject: A pointer to the underlying kernel object (e.g., a task, a thread, or a user-client). This pointer is PAC-signed.
ip_context: A 64-bit context value, also PAC-signed.

If an attacker attempts to forge a port, they must generate a valid signature for the ip_kobject pointer. Without the APDAKey (Data Key A), the kernel will panic upon AUT execution during message delivery.

6.1.2 The IPC Space (`ipc_space`) and the Global Name Server

Every task (process) in macOS has an associated IPC Space (ipc_space). This structure acts as the translation layer between userland integer handles (mach_port_name_t) and kernel objects (ipc_port *, ipc_pset *, etc.).

The Translation Table (is_table):
Each IPC space is backed by a dynamically sized array of IPC Entries (ipc_entry), commonly referred to as the is_table / ipc_entry_table.

Index:
The userland handle (e.g. 0x103) encodes:
- A low-order index into the is_table, and
- High-order generation bits used to detect stale handles.
Entry (ipc_entry):
Each entry contains (simplified):
- ie_object: A pointer to the underlying ipc_port or ipc_pset. On arm64e/Tahoe, this pointer is protected with pointer authentication (PAC) so that corruption of the raw bits does not yield a usable kernel pointer.
- ie_bits: A bitfield encoding:
  - Rights (send, receive, send-once, etc.).
  - The generation count for that slot.
  - Additional flags (e.g. dead-name state).

The Lookup Process (ipc_right_lookup_write):
When a thread executes mach_msg() to send to some msgh_remote_port:

The kernel retrieves the current task’s IPC space:
ipc_space_t space = current_task()->itk_space;
It decodes the mach_port_name_t to obtain the index and generation and indexes into space->is_table.
It checks ie_bits:
- Generation matches the high bits of the name?
- Required right present (e.g. MACH_PORT_RIGHT_SEND for a send).
On arm64e, it authenticates the ie_object pointer using the appropriate kernel PAC key and context.
If all checks succeed, it obtains the ipc_port and proceeds with message delivery.

This indirection is what allows the kernel to revoke or recycle ports while making stale userland handles harmless: the generation mismatch will cause lookups to fail instead of returning the wrong object.

The Global Name Server:
Mach itself does not implement a string-based global namespace in the kernel. The kernel only knows about ports and rights; it does not know what "com.apple.windowserver" means.

The mapping from string service names → mach_port_t is implemented entirely in userland by the bootstrap server, which on macOS is launchd.

Special ports:
The kernel does maintain a small set of “special ports” on host and task objects. Relevant here:
- HOST_PORT: A send right representing the host (realhost).
- HOST_PRIV_PORT: The privileged host port (see Section 6.2).
- TASK_BOOTSTRAP_PORT: The task’s handle to the bootstrap server (typically a port managed by launchd for that task’s domain).

When a process calls:

bootstrap_look_up(bootstrap_port, "com.apple.foo", &service_port);

or uses the XPC equivalent, it is really sending a Mach message to whatever port is stored in its TASK_BOOTSTRAP_PORT slot. launchd receives that message and resolves "com.apple.foo" into a Mach port according to its internal job graph and policy.

6.1.3 Copy-on-Write (CoW) optimizations in Out-of-Line (OOL) message passing

Mach messages are not limited to small scalars. They can transfer massive amounts of data using Out-of-Line (OOL) descriptors. This mechanism relies on Virtual Memory (VM) tricks rather than data copying, making it highly efficient but historically dangerous.

The Mechanism:

Sender: Includes a mach_msg_ool_descriptor_t in the message, pointing to a buffer in its address space (e.g., 100MB of data).
Kernel Processing: The kernel does not copy the 100MB. Instead, it walks the sender's VM map.
Copy-on-Write (CoW): The kernel marks the physical pages backing that buffer as Read-Only in the sender's map.
Receiver: The kernel maps those same physical pages into the receiver's address space, also as Read-Only.
Faulting: If either the sender or receiver tries to write to the buffer, the MMU triggers a fault. The kernel catches this, allocates a new physical page, copies the data, and updates the mapping for the writer. This preserves the illusion of a copy.

The Tahoe/SPTM Intersection:
In the Tahoe architecture, this VM manipulation is complicated by the SPTM.

Permission Downgrade: When the kernel marks the pages as CoW (Read-Only), it cannot simply update the PTEs. It must issue a GENTER call (sptm_protect or sptm_map) to the SPTM to downgrade the permissions of the physical pages in the sender's address space.
The Vulnerability Class: This complexity introduces a race window. If the kernel logic fails to correctly lock the VM map object before requesting the SPTM update, or if the SPTM state machine has a logic flaw regarding shared pages (refcount > 1), it might be possible to modify the physical page after the message has been "sent" but before the receiver reads it. This is known as a Double Fetch or Physically-Backed-Virtually-Disjoint attack.

RE Focus:
Analyze vm_map_copyin and vm_map_copyout in the XNU source (or binary). Look for how vm_map_entry structures are flagged with needs_copy and how these flags translate into SPTM calls. The interaction between Mach IPC (which assumes it controls VM) and the SPTM (which actually controls VM) is the friction point where new bugs will likely emerge.

6.2 The `host_priv` Port

In the lexicon of XNU exploitation, the Host Privilege Port (host_priv) has historically been synonymous with “Game Over.” It is not the kernel task port itself; rather, it is a privileged Mach port on the global host object (realhost) that unlocks host-level operations and special ports. In older exploitation chains, host_priv was often the stepping stone to obtain a send right to kernel_task (TFP0) via interfaces such as host_get_special_port or task_for_pid(0, …).

6.2.1 The “God Mode” Handle: Generation and Restriction

The host_priv port is backed by the kernel’s global host object (realhost). Unlike a task port, which maps to a task_t, the host_priv port is a privileged view of the host object that unlocks host-level operations (for example, access to special ports and certain system configuration controls).

Generation at boot

During early bootstrap in osfmk/kern/host.c, XNU initializes the host subsystem:

host_init():
Allocates and initializes the realhost structure.
Port allocation:
Calls ipc_port_alloc_kernel() (or equivalent helpers) to create the Mach port for the host.
Kobject association:
Associates the realhost pointer with the port’s ip_kobject / context fields.

On arm64e/Tahoe:

The ip_kobject (or related kobject pointer) is stored as a PAC-signed kernel pointer, using one of the kernel’s data-pointer keys with the port address (or similar) as context.
This prevents simple “write some other kernel address into ip_kobject” attacks, even given a raw kernel read/write primitive: tampered pointers will not authenticate when used.

Distribution

The system is conservative about who gets host_priv. Typical holders are:

kernel_task:
Owns the receive right for the host-privileged port.
Privileged daemons (for example, launchd, kernelmanagerd):
Obtain send rights to host_priv via host_get_host_priv_port() or the special-port mechanism, so they can:
- manage special ports (host_get_special_port, host_set_special_port), and
- perform host-level operations on behalf of the rest of the system.

The exact set of daemons that receive host_priv can vary by OS release, but it is a very small, explicitly entitled group.

The “TFP0” chain in Tahoe

Historically, a common pattern was:

host_get_host_priv_port(mach_host_self(), &host_priv);
task_for_pid(mach_task_self(), 0, &kernel_task_port);

On modern macOS / Tahoe, several layers weaken this chain:

task_conversion_eval and SIP:
Even if a caller presents host_priv, task_for_pid(0, …) is gated by System Integrity Protection (SIP) and related policy hooks. With SIP enabled, conversion to kernel_task is denied for untrusted callers.
Immutable kernel regions via KIP/SPTM:
Even if an attacker somehow:
- bypasses SIP/task conversion checks, and
- obtains a kernel_task port,
the system’s integrity protections still constrain what that port can do safely:
- code pages in the Kernel Integrity Protection (KIP) region are loaded and marked read-only by iBoot/SPTM,
- page tables and “data-const” regions are protected by SPTM frame typing,
- attempts to use vm_write / mach_vm_write to modify such protected regions can trigger integrity violations and system panic rather than giving persistent arbitrary code execution.

In effect, on Tahoe-era systems, host_priv is a high-leverage control primitive and a prerequisite for a number of powerful operations, but it is no longer, by itself, a trivial “write-anywhere in kernel text” primitive once KIP/SPTM and SIP are taken into account.

6.2.2 Task Special Ports: The Privileged Directory

While host_priv itself is restricted, it is also the gateway into a table of host special ports that act as privileged entry points for various subsystems. These ports are accessed via host_get_special_port() and host_set_special_port().

Internally, the realhost structure maintains an array such as:

ipc_port_t special[HOST_MAX_SPECIAL_PORT + 1];

where specific indices are reserved for particular subsystems.

Critical special ports (by name)

A non-exhaustive set of important host special ports:

HOST_AUTOMOUNTD_PORT:
Port used by the kernel to talk to the automounter (automountd) to initiate filesystem mounts.
HOST_SEATBELT_PORT:
Control port for the sandbox subsystem (seatbelt / sandbox.kext). Possession of this port gives a daemon the ability to receive sandbox configuration and policy messages.
HOST_KEXTD_PORT:
Port used for communicating with the kernel extension manager (kextd / kernelmanagerd). Historically has been involved in flows that could be abused to force loading of kexts; on Tahoe, these flows are constrained by driver signing, KCs, and TXM/LocalPolicy.
HOST_AMFID_PORT:
Port used to talk to the Apple Mobile File Integrity daemon (amfid) for code-signing validation requests.

The actual numeric IDs (indices into special[]) for these ports are defined in headers like host_special_ports.h and are not simple small integers like 1 or 7; they are offsets from HOST_MAX_SPECIAL_KERNEL_PORT. For most reverse-engineering and exploitation work, the symbolic names and behaviors matter more than the concrete index values.

RE Focus: The host_set_special_port trap

A classic post-exploitation idea is:

Overwrite a host special port (e.g. the KEXTD port) with a port you control, so you can intercept kernel upcalls intended for that subsystem.

In principle:

If an attacker can get host_priv and then call:
```
host_set_special_port(host_priv,
                      HOST_KEXTD_PORT,
                      attacker_port);
```
the kernel will now send all “kextd” notifications to attacker_port instead.

Mitigations in modern macOS include:

Entitlement and policy gating:
host_set_special_port is restricted:
- It requires a host-privileged port.
- It is further gated by entitlements and code-signing checks; in practice, only launchd and a very small number of highly privileged system daemons are allowed to call it successfully.
Confused-deputy / race hardening:
Attackers therefore look for:
- Bugs that allow racing or bypassing entitlement checks.
- Confused-deputy situations where a daemon that does have the entitlement can be coerced into calling host_set_special_port with an attacker-controlled port name.

From a reversing perspective, mapping which daemons hold both host_priv and the relevant private entitlements is a critical part of understanding the real attack surface around host_set_special_port.

6.2.3 RE Focus: Fuzzing Mach Message Parsing (MIG)

Since host_priv exposes a wide attack surface via the Mach IPC interface, it is a primary target for fuzzing. The kernel handles these messages using the Mach Interface Generator (MIG).

The host_priv_server Routine:
When a message is sent to host_priv, the kernel's IPC dispatcher calls host_priv_server. This is an auto-generated function that deserializes the Mach message and dispatches it to the implementation (e.g., kern_host.c).

Vulnerability Classes in MIG:

Type Confusion: MIG relies on the message header to define the size and type of arguments. If the userland client sends a malformed message (e.g., claiming a descriptor is OOL memory when it is actually inline data), the kernel's unmarshaling logic might misinterpret the data, leading to heap corruption.
Reference Counting Leaks: If a MIG routine returns an error (e.g., KERN_INVALID_ARGUMENT) after it has incremented the reference count on a port or VM object but before it consumes it, the object leaks. In the kernel, this can lead to a refcount overflow (though 64-bit refcounts make this hard) or a Use-After-Free if the cleanup logic is flawed.
TOCTOU on OOL Memory: As discussed in Section 6.1.3, if the message includes Out-of-Line memory, the kernel maps it Copy-on-Write. If the MIG handler verifies the content of the memory and then uses it later, the userland process might be able to race the kernel and modify the physical page (via a side-channel or SPTM state confusion) between the check and the use.

The Tahoe Hardening:
In the Tahoe kernel, MIG-generated code has been hardened with PAC.

Function Pointers: The dispatch tables used by host_priv_server are signed.
Context: The ipc_kmsg structure (representing the message in flight) is heavily protected to prevent modification of the message contents after validation but before processing.

However, logic bugs in the implementation of the host calls (the C functions called by MIG) remain reachable. For example, host_processor_set_priv allows manipulating CPU sets. If the logic fails to account for a processor being in a low-power state or being managed by an Exclave, it could trigger an inconsistent state in the scheduler.

7.0 IOKit & Driver Architecture

While the Mach subsystem provides the primitives for IPC and scheduling, IOKit provides the object-oriented framework for device drivers. Historically, IOKit has been the "soft underbelly" of the XNU kernel. Written in a restricted subset of C++, it relies heavily on virtual function dispatch, complex inheritance hierarchies, and manual reference counting (OSObject::retain/release).

In the Tahoe architecture, IOKit has undergone a radical hardening process. The transition to Apple Silicon has allowed Apple to enforce strict Control Flow Integrity (CFI) on C++ objects using PAC, while Kernel Integrity Protection (KIP) enforces the immutability of the driver code itself, with the SPTM protecting the page tables that describe those regions.

7.1 IOKit Initialization

The initialization of IOKit is the bridge between the static hardware description provided by iBoot (the Device Tree) and the dynamic, runtime object graph that constitutes the macOS driver environment.

7.1.1 The IORegistry: Populating the Device Tree into C++ Objects

When the kernel boots, the hardware topology is described by the Flattened Device Tree (FDT). Unlike previous architectures where the FDT pointer might have been passed in a raw register, in the current XNU ABI, the FDT pointer is stored in the deviceTreeP field of the boot_args structure, which is passed in x0 to the kernel entry point _start. IOKit's first major task is to hydrate this binary blob into a live graph of IORegistryEntry objects.

The IOPlatformExpert:
The bootstrap process is driven by the IOPlatformExpert class (specifically IOPlatformExpertDevice on Apple Silicon).

Unflattening: The kernel parses the FDT. For every node in the tree (e.g., arm-io, uart0, aic), it instantiates an IORegistryEntry.
The IODeviceTree Plane: These objects are attached to the IODeviceTree plane of the Registry. This plane represents the physical topology as reported by iBoot.
Property Mapping: Properties from the FDT (like reg, interrupts, compatible) are converted into OSData, OSString, or OSNumber objects and attached to the registry entries.

Matching and Driver Loading:
Once the Registry is populated, IOKit begins the Matching phase (IOService::startMatching).

The compatible String: IOKit iterates over the registry entries. It compares the compatible property (e.g., apple,s5l8960x-uart) against the IOKitPersonalities dictionary defined in the Info.plist of every loaded driver.
The Probe/Start Lifecycle: When a match is found, the driver's C++ class is instantiated.
- init(): Constructor.
- probe(): The driver verifies the hardware is actually present (rarely used on SoCs where hardware is static).
- start(): The driver initializes the hardware, maps MMIO regions, and registers interrupts.

RE Focus: The "Missing" Hardware:
On Tahoe systems, empirical observation reveals gaps in the IORegistry compared to the raw Device Tree.

Reserved Regions: The SPTM and TXM reserve specific hardware blocks (e.g., the Secure Storage controller or specific GPIO banks for privacy LEDs).
Filtering: While not explicitly documented as an SPTM feature, reverse engineering suggests that during the unflattening process, nodes corresponding to physical ranges reserved by the SPTM are omitted from the IODeviceTree. This effectively makes secure hardware invisible to the OS, preventing the kernel from even attempting to map the MMIO registers for these protected blocks.

7.1.2 Boot, System, and Auxiliary Kernel Collections

Gone are the days of loading individual .kext bundles directly from /System/Library/Extensions at boot. To optimize startup and enforce stronger integrity guarantees, macOS now uses Kernel Collections.

Boot Kernel Collection (BKC)

The BootKC is a large, prelinked Mach-O, delivered as an Image4 payload (commonly labeled Ap,BootKernelCollection):

Content:
The BKC bundles:
- The XNU kernel.
- All “essential” drivers required to:
  - Initialize low-level hardware.
  - Mount the root filesystem.
  - Bring up enough of the graphics/console stack to start userland and show the boot UI.
Linkage:
All included kexts are prelinked against the kernel:
- Symbol resolution is performed at build-time.
- No relocations or link-edit work is needed in the early boot path.
Protection (KIP/SPTM):
The BKC is loaded by iBoot into a region managed by Kernel Integrity Protection (KIP) and the Secure Page Table Monitor (SPTM):
- The physical pages backing BKC code are tracked and locked down before XNU runs.
- Page-table entries mapping these frames are subject to SPTM policy: kernel attempts to make them writable or executable in unexpected ways can be blocked or cause a panic.
- This makes kernel text and core boot drivers effectively immutable from EL1, even if an attacker gains kernel_task.

System Kernel Collection (SystemKC)

The SystemKC holds additional Apple-provided drivers that are not strictly required to mount root or start launchd:

Examples include Wi-Fi, Bluetooth, audio, and other device drivers.
Like the BKC, SystemKC contents are:
- Prelinked.
- Signed by Apple and loaded from the immutable System volume.
- Covered by the same KIP/SPTM enforcement model once mapped.

Auxiliary Kernel Collection (AuxKC)

The AuxKC is the “expansion slot”:

It contains:
- Third-party kexts.
- Apple-signed kexts that are treated as auxiliary (e.g. optional features, development-only drivers).
Loading path:
- kernelmanagerd (userland) is responsible for assembling and signing an Auxiliary KC based on currently-installed third-party drivers.
- It then asks the kernel to load this collection at runtime once the system is up enough to trust userland decisions.
Verification and sealing:
- The kernel verifies the AuxKC’s signature.
- On Tahoe-era systems, this verification is tied into TXM / LocalPolicy:
  - Policy must allow third-party kexts in the current boot configuration.
  - The AuxKC’s provenance and contents must satisfy platform rules.
- Once accepted, the pages for the AuxKC are mapped and then “sealed”:
  - Their mappings transition to code-like protections under SPTM.
  - After sealing, they are enforced similarly to BKC/SystemKC code (immutable from the kernel’s own point of view).

RE implication

For reverse engineering and exploitation:

BKC/SystemKC drivers:
- Have stable offsets relative to the kernel slide once you know the collection layout.
- Live in regions that are protected early and rarely change at runtime.
AuxKC drivers:
- Are loaded later and can have randomized placement.
- You often need to:
  - Traverse kernel data structures (kmod_info, KC descriptors) at runtime to find their base addresses.
  - Account for the fact that their text regions are still covered by SPTM after sealing, even though they arrived late.

7.1.3 RE Focus: PAC-signing of C++ Vtables (`OSObject`) and `BLRAA`

The OSObject class is the root of the IOKit inheritance hierarchy. In C++, dynamic dispatch is handled via Virtual Tables (vtables)—arrays of function pointers. Historically, attackers would overwrite the vtable pointer in an object to point to a fake vtable controlled by the attacker (vtable hijacking).

In the arm64e architecture, Apple has fundamentally altered the C++ ABI for kernel code to mitigate this.

The Signed Vtable Pointer:
In a standard C++ object, the first 8 bytes are the pointer to the vtable. In XNU on arm64e, this pointer is signed.

Key: APDAKey (Data Key A).
Context: The salt is 0. Implementations consistently use a zero context (salt=0) for the object's vtable pointer (vptr) to support standard C++ semantics like memcpy and realloc. This allows objects to be moved in memory without needing to resign the vptr. Address-based diversity is applied to the function pointers inside the vtable, not to the vptr itself.
$$ \texttt{SignedPtr} = \texttt{PAC}(\texttt{VtableAddr}, \texttt{Key=APDA}, \texttt{Context}=0) $$

The Signed Vtable Entries:
The function pointers inside the vtable are signed using the APIAKey (Instruction Key A).

Context: The salt incorporates the entry's storage address and a hash of the mangled method name. This prevents moving entries between vtables.

The BLRAA Dispatch:
When the kernel calls a virtual function (e.g., object->release()), the compiler emits a specialized instruction sequence:

LDR     x0, [x20]       ; Load the object pointer
LDR     x16, [x0]       ; Load the signed vtable pointer
AUTDA   x16, xzr        ; Authenticate Data Key A, Context = 0 (per docs)
LDR     x10, [x16, #0x18] ; Load the target function pointer from the vtable
BLRAA   x10, x16        ; Branch with Link, Authenticating Key A, Context = Vtable Address

Note the two-stage authentication:

AUTDA: Authenticates that the vtable pointer is valid. If the pointer was overwritten, x16 becomes a canonical non-valid pointer.
BLRAA: The function pointers inside the vtable are also signed. The BLRAA instruction authenticates the function pointer (using the vtable address as context) and branches.

The "Recursive" PAC:
This creates a chain of trust:

The Object trusts the Vtable Pointer (via APDAKey).
The Vtable trusts the Function Pointers (via APIAKey).
KIP/SPTM trusts the Vtable Memory (via code immutability).

For a reverse engineer, this means that patching a vtable in memory is impossible (KIP/SPTM), and forging an object requires the ability to sign pointers with the APDAKey—a capability that requires a "Signing Oracle" gadget, which BTI aims to eliminate.

7.2 DriverKit (dexts)

The introduction of DriverKit represents a strategic retreat for the XNU kernel. For decades, the kernel’s attack surface was effectively the sum of the core kernel plus every third-party driver loaded into the address space. A vulnerability in a Wacom tablet driver or a USB-to-Serial adapter was functionally identical to a vulnerability in the scheduler: both yielded EL1 code execution.

DriverKit bifurcates this model by moving hardware drivers into userland, executing as System Extensions (.dext). While they look and feel like drivers to the developer (using a C++ subset similar to Embedded C++), architecturally they are unprivileged processes. In the Tahoe architecture, this isolation is not merely a sandbox; it is a hardware-enforced chasm guarded by the TXM and SPTM.

7.2.1 Moving drivers to userland: `IOUserClient` and Entitlement Checks

A dext is an ordinary userland process (usually running as root but confined by a dedicated sandbox and entitlements). It has no direct access to the kernel’s task port and can only exercise kernel functionality via IOUserClient interfaces that the kernel explicitly exposes.

The IOUserServer Proxy:
When a dext is matched and loaded (managed by kernelmanagerd), the kernel instantiates a shadow object known as IOUserServer. This kernel-side object acts as the proxy for the userland driver.

The Shim: When the kernel needs to call a function in the driver (e.g., Start()), it calls a method on IOUserServer.
Serialization: IOUserServer serializes the arguments into a specialized Mach message format (distinct from standard MIG).
The Upcall: The message is sent to the dext process. The DriverKit runtime (linked into the dext) deserializes the message and invokes the implementation of the IOService subclass in userland.

The IOUserClient Interface:
Conversely, when the dext needs to talk to the kernel (e.g., to register an interrupt handler or map memory), it cannot call kernel APIs directly. It uses IOUserClient.

Restricted API Surface: The dext can only invoke a specific subset of kernel functionality exposed via IOUserClient traps. These traps are heavily scrutinized.
OSAction: Interrupts are no longer handled via ISRs (Interrupt Service Routines) in the driver. Instead, the kernel handles the physical IRQ, masks it, and dispatches an OSAction event to the dext via a Mach notification. This eliminates the entire class of vulnerabilities related to interrupt context safety and spinlock deadlocks in third-party code.

Entitlements as the Gatekeeper (TXM Enforcement):
In Tahoe, the ability of a dext to bind to specific hardware is governed by Entitlements.

Hardware Binding: A dext cannot simply mmap any MMIO region. It must possess specific entitlements (e.g., com.apple.developer.driverkit.transport.usb) to access specific device families.
TXM Verification: When kernelmanagerd launches a dext, the system verifies its signature and entitlements against LocalPolicy and trust caches. On SPTM/TXM-equipped systems, these checks are enforced below XNU, so a compromised kernelmanagerd cannot bypass them. If the TXM returns a failure, the kernel refuses to establish the IOUserServer link, and the driver fails to start.

RE Focus: The IOUserClass Metaclass:
Reverse engineering a dext requires understanding the OSMetaClass infrastructure in userland. The dext binary contains OSMetaClass information that describes the RPC interface. By parsing the __DATA,__const sections, one can reconstruct the vtables and the mapping between the kernel-side dispatch IDs and the userland C++ methods.

7.2.2 Memory Mapping Constraints and IOMMU (DART) Protection

The most dangerous capability of a driver is Direct Memory Access (DMA). A malicious or buggy driver could program a peripheral (like a GPU or Network Card) to write data to physical address 0x0 (or wherever the kernel text resides), bypassing CPU-enforced protections like KTRR.

To mitigate this, Apple Silicon employs a pervasive IOMMU architecture known as DART (Device Address Resolution Table).

The DART Architecture:
Every DMA-capable peripheral on the SoC sits behind a DART. The device does not see Physical Addresses (PA); it sees I/O Virtual Addresses (IOVA). The DART translates IOVA → PA, enforcing permissions (Read/Write) at the page level.

DriverKit Memory Model:

IOMemoryDescriptor: When a dext allocates a buffer for DMA, it creates an IOMemoryDescriptor.
Mapping: The dext calls IOMemoryDescriptor::CreateMapping. This triggers a call into the kernel.
The Kernel's Role: The kernel allocates physical pages (XNU_DATA) and pins them.
DART Programming: The kernel programs the DART associated with the specific hardware device controlled by the dext. It maps the physical pages to an IOVA range visible to that device.

The Tahoe/SPTM Enforcement:
In the Tahoe architecture, the kernel is no longer trusted to program the DARTs directly. If the kernel could write to DART registers, it could map the kernel's own text segment as writable to the GPU, then tell the GPU to overwrite it (a DMA attack).

SPTM Ownership: The physical pages containing the DART translation tables (or the MMIO registers controlling the DART) are typed as SPTM_PRIVATE or a specific hardware-protected type in the Frame Table.
The sptm_map_iommu Selector: When the kernel needs to map a buffer for a dext, it issues a GENTER call to the SPTM.
Validation: The SPTM verifies that the physical pages being mapped are owned by the dext (or are valid shared memory). It strictly forbids mapping any page typed XNU_TEXT, PAGE_TABLE, or SPTM_PRIVATE into a DART.
Execution: The SPTM performs the write to the DART hardware.

MMIO Mapping Restrictions:
Similarly, when a dext needs to control hardware registers (MMIO), it requests a mapping.

The kernel cannot simply map physical device memory into the dext's address space.
SPTM Validation: The SPTM only honors MMIO mapping requests that target ranges it recognizes as device registers for the given driver or device; ranges associated with secure components (SEP, KTRR controller) are excluded.
This ensures that a USB driver can only map the USB controller's registers, and cannot map the registers for the Secure Enclave Mailbox or the KTRR controller.

RE Implication:
Exploiting a dext to gain kernel privileges is exponentially harder in Tahoe. Even if you gain code execution in the dext (Userland), you cannot issue arbitrary syscalls (sandbox), you cannot map kernel memory (VM isolation), and you cannot use the hardware device to perform DMA attacks against the kernel (SPTM-enforced DART). The attacker is contained within a hardware-enforced cage, limited to the specific capabilities of that one peripheral.

7.3 The Graphics Stack (AGX)

If the XNU kernel is the central nervous system, the Apple Graphics (AGX) stack is a secondary, alien brain grafted onto the SoC. On M-series silicon, the GPU is not merely a peripheral; it is a massive, autonomous compute cluster running its own proprietary operating system, managing its own memory translation, and executing a command stream that is almost entirely opaque to the main OS.

For the reverse engineer, AGX represents the largest and most complex attack surface in the kernel. The driver (AGX.kext) is enormous, the firmware is encrypted (until load), and the hardware interface is undocumented. In the Tahoe architecture, Apple has moved to aggressively sandbox this beast, wrapping the GPU's memory access in strict DART (Device Address Resolution Table) policies enforced by the SPTM to prevent DMA-based kernel compromises.

7.3.1 RTKit: The Proprietary RTOS running on the GPU Coprocessor (ASC)

The GPU does not execute driver commands directly. Instead, the M-series SoC includes a dedicated Apple Silicon Coprocessor (ASC)—typically a hardened ARMv8-R or Cortex-M class core—that manages the GPU hardware. This coprocessor runs RTKit, Apple’s proprietary Real-Time Operating System.

The Firmware Blob:
The kernel driver does not contain the logic to drive the GPU hardware registers directly. Instead, upon initialization (AGX::start), it loads a firmware payload from a firmware bundle on disk or embedded in the kext.

Format: The firmware is a standard Mach-O binary, often multi-architecture.
Sections: It contains __TEXT and __DATA segments just like a userland program.
RTKit Structure: Reverse engineering the firmware reveals a microkernel architecture. It has a scheduler, an IPC mechanism, and a set of "Endpoints" (services).

The RTKit IPC Protocol:
Communication between the XNU kernel (AGX.kext) and the ASC (RTKit) occurs via a shared memory mailbox protocol.

Mailbox Registers: The AP writes to a specific MMIO register to ring the doorbell of the ASC.
Message Buffer: The message payload is placed in a shared memory ring buffer.
Endpoints: The protocol is endpoint-based. Reverse engineering identifies specific service IDs running on the ASC, such as:
- EP_PM: Power Management (Voltage/Clock gating).
- EP_GR: Graphics Rendering (Command submission).
- EP_COMP: Compute (GPGPU/Metal).

RE Focus: The RTKit State Machine:
The AGX.kext contains extensive logging strings and state tracking for RTKit. By analyzing the RTKit class in the kext, one can reconstruct the message structures.

Crash Logs: When the GPU hangs, RTKit writes a "Coredump" to a shared buffer. The kernel captures this. Analyzing these logs reveals the internal memory layout of the ASC and the state of the GPU pipeline at the time of the crash.
Filter Bypass: Historically, vulnerabilities existed where the kernel could send malformed IPC messages to the ASC, causing memory corruption inside the GPU firmware. While this doesn't directly yield Kernel R/W, compromising the ASC allows an attacker to use the GPU as a confused deputy for DMA attacks (see 7.3.3).

7.3.2 `IOMobileFramebuffer` (IOMFB): Secure Framebuffers and Exclave Compositing

While AGX.kext handles rendering, IOMobileFramebuffer.kext (IOMFB) handles the display controller (DCP). This driver is responsible for the "Swap Chain"—taking the rendered frames and scanning them out to the display panel.

The Unified Memory Architecture (UMA):
On Apple Silicon, the Framebuffer is just a region of system DRAM. WindowServer (userland) renders into an IOSurface. The physical pages backing this surface are passed to IOMFB, which programs the Display Coprocessor (DCP) to read from them.

The Security Criticality:
IOMFB is a high-value target because it handles complex shared memory structures (IOMFBSharedMemory) mapped into both the kernel and userland (WindowServer).

Fuzzing Surface: The Connect method and external methods of IOMobileFramebufferUserClient have historically been riddled with race conditions and bounds-checking errors.

Tahoe and the "Secure Overlay":
In the Tahoe architecture, IOMFB's control over the display is no longer absolute. To support the Hardware Privacy Indicators (Green/Orange dots), reverse engineering suggests the display pipeline has been bifurcated.

Standard Pipe: Managed by IOMFB/WindowServer. Draws the desktop/apps.
Secure Pipe: Managed by an Exclave. Draws the privacy indicators.

Hardware Compositing:
The compositing of these two pipes happens in the display hardware, not in memory.

The Exclave owns a small, reserved framebuffer region.
The Display Controller overlays this region on top of the standard framebuffer during scanout.
Immutability: Because the Secure Pipe's framebuffer memory is owned by the Exclave (and protected by the SPTM), neither the kernel nor the GPU can write to it. This guarantees that if the camera is on, the green dot will be visible, even if the kernel is compromised.

7.3.3 DART: The IOMMU Wall and DMA Containment

The GPU is effectively a DMA engine with the capability to read and write vast swathes of system memory. Without restriction, a compromised GPU firmware (or a malicious shader exploiting a GPU hardware bug) could overwrite kernel text or page tables.

To prevent this, the AGX hardware—and indeed every DMA-capable peripheral on the Apple Silicon SoC—sits behind a strict IOMMU known as the DART (Device Address Resolution Table).

DART Architecture and Stream IDs (SIDs):
The DART translates Device Virtual Addresses (DVA) used by the peripheral into Physical Addresses (PA) in DRAM. However, the translation is not monolithic; it is segmented by the source of the traffic.

Stream IDs (SIDs): Every transaction on the SoC's Network-on-Chip (NoC) carries a hardware-generated Stream ID identifying the initiator (e.g., GPU Firmware, Vertex Fetcher, Display Controller).
Context Banks: The DART maintains multiple translation contexts (similar to distinct TTBR roots).
SID Matching: The DART hardware is configured to map specific SIDs to specific Context Banks. This allows isolation between different workloads on the same peripheral (e.g., isolating WindowServer rendering commands from a background compute shader).

The Tahoe Enforcement (SPTM):
In pre-Tahoe systems, the kernel (AGX.kext or IOMapper) managed the DART page tables and the SID configuration registers directly. This meant a kernel attacker could disable DART, remap SIDs to privileged contexts, or map kernel memory into the GPU's address space to bypass KTRR.

In Tahoe, DART management is privileged to the SPTM.

Ownership: The physical pages containing the DART translation tables (L1/L2 TTEs) and the MMIO registers controlling SID configuration are typed as SPTM_PRIVATE (or a specific IOMMU_TABLE type) in the Frame Table.
Mapping Requests: When AGX.kext needs to map a user's IOSurface for GPU access:
- It pins the user pages.
- It issues a GENTER call (Selector sptm_map_iommu).
- It passes the DART ID, the Context ID, the DVA, and the PA.
Validation: The SPTM verifies:
- The PA is valid USER_DATA (not Kernel Text, not Page Tables).
- The DART ID corresponds to the GPU.
- SID Integrity: Crucially, the SPTM enforces the immutable binding between SIDs and Contexts. It ensures that the kernel cannot reconfigure the DART to allow an untrusted SID (e.g., the Neural Engine) to write to a Context Bank reserved for the Secure Enclave or Display Pipe.
Execution: The SPTM writes the DART PTE.

RE Focus: The "GART" Attack Surface:
Despite SPTM protection, the logic requesting the mapping still resides in the kernel.

Aliasing: Can the kernel trick the SPTM into mapping the same physical page to two different DART contexts with different permissions?
Stale TLBs: Does the SPTM correctly flush the DART TLB (tlb_flush) immediately after unmapping? If not, the GPU might retain access to a page that has been freed and reallocated to the kernel, leading to a Use-After-Free via DMA.
Side Channels: The DART configuration registers (e.g., TCR, TTBR, and SID match registers) are trapped by the hardware to GL2. Attempting to write to the DART control base address from EL1 should trigger a synchronous exception. Reverse engineering the IOMapper class in IOKit will reveal the specific GENTER trampolines used to bridge these operations.

8.0 Userland Bootstrap: The Birth of PID 1

The initialization of the XNU kernel culminates in mounting the root filesystem (the Signed System Volume) and creating the first userland process. In traditional UNIX systems, this is init (PID 1). On macOS, this role is fulfilled by launchd.

launchd is not just a SysV-style init. It is:

The process supervisor that manages the lifecycle of daemons and agents.
The Mach bootstrap server, providing the string-to-port name service for most of userland.
A central policy enforcement point for IPC visibility and service availability.

In the Tahoe architecture, launchd is also the first long-lived user process to run under the full scrutiny of the Trusted Execution Monitor (TXM) and associated integrity mechanisms. Its successful launch marks the handoff from the measured, firmware-controlled boot world to the userland environment.

8.1 `launchd`: The Mach Port Broker

The transition from kernel mode to user mode is effectively one-way for the thread that becomes PID 1: once it crosses into userland, it never returns to the kernel in its original identity.

After early initialization in bsd_init() (mounting root, bringing up the BSD subsystem), the kernel:

Spawns a special kernel thread (often referred to conceptually as the bsdinit_task).
Uses bsd_utaskbootstrap() to:
- Allocate initproc (PID 1) and its backing task_t.
- Load the launchd Mach-O binary into that task via load_init_program().

From this point on:

launchd becomes the root of the userland process tree.
All subsequent processes are, ultimately, descendants of PID 1.
launchd’s management of Mach ports and bootstrap namespaces becomes the primary mechanism by which services discover each other and enforce IPC-based policy.

8.1.1 Transition from Kernel to Userland: The First `execve`

The kernel routine bsd_init() (in bsd/kern/bsd_init.c) orchestrates the end of early boot:

Root filesystem mount:
It ensures the Signed System Volume is mounted and ready.
PID 1 construction (bsd_utaskbootstrap / cloneproc):
The kernel:
- Creates initproc as PID 1 by cloning from the kernel’s internal template process, with special flags (CLONEPROC_INITPROC).
- Allocates the corresponding task_t and thread structures.
load_init_program() – kernel-side execve of /sbin/launchd:
Instead of a user process calling execve("/sbin/launchd", ...), the kernel:
- Loads the Mach-O for /sbin/launchd (backed in modern systems by the OS Cryptex, even though the path appears as /sbin/launchd).
- Constructs the initial user address space:
  - Maps __TEXT read/execute.
  - Maps __DATA read/write.
- Sets up the initial user thread state (PC, stack, registers) as if an execve had just succeeded.
Trust and integrity checks (conceptual model):
On Tahoe systems:
- The code signature and CDHash of launchd are validated against the Static Trust Cache and platform policy.
- TXM/SPTM participate in ensuring that:
  - Only a measured, signed launchd binary becomes PID 1.
  - Its text pages are mapped in a way that respects kernel integrity protection (no ad-hoc remapping to writable/executable later without violating SPTM policy).

The exact firmware call sequence is implementation detail, but the net effect is: if launchd is not exactly the expected, signed binary, the system does not proceed into userland.

The host_priv handoff

As part of bringing up the userland environment:

The system needs a trusted process that can:
- Talk to host-level interfaces (host_get_special_port, etc.).
- Manage systemwide services and kext/kc configuration.

launchd is that process. During or shortly after PID 1 construction:

The kernel ensures that launchd can obtain the host-privileged port (host_priv) by:
- Providing a host send right via initial special ports, or
- Allowing launchd to call host_get_host_priv_port() successfully.
Subsequent privileged daemons (e.g. kernelmanagerd) obtain their own host-level capabilities via launchd-mediated configuration or direct host_get_special_port calls, subject to entitlements.

launchd is therefore the first userland holder of host-level control needed to configure the rest of the system, but it is not necessarily the only holder for the entire lifetime of the OS.

8.1.2 Initializing the Bootstrap Port (Subset of the Name Service)

Mach does not provide any built-in string-based name service. Name→port mappings are implemented in userland by the bootstrap server, which on macOS is launchd.

Bootstrap port assignment

Every task in XNU has a special port slot, TASK_BOOTSTRAP_PORT. For PID 1:

When launchd is created, the kernel associates a bootstrap server port with launchd’s TASK_BOOTSTRAP_PORT.
For child processes spawned by launchd, this slot is:
- Inherited from the parent, or
- Replaced with a more restricted bootstrap port representing a subset namespace (e.g. per-user or per-session domain).

From userland’s perspective:

bootstrap_port in the bootstrap_* APIs (and the default XPC bootstrap connection) is whatever send right is stored in TASK_BOOTSTRAP_PORT.

Namespace hierarchy (domains)

Modern launchd organizes the bootstrap namespace into domains, which correspond roughly to what launchctl exposes as specifiers:

system/ – The system-wide daemon domain (LaunchDaemons, root services).
user/<uid>/ – Per-UID domains for LaunchAgents.
gui/<uid>/ – GUI domains for interactive sessions per user.
login/<asid>/ or session/<asid>/ – Per-login/per-ASID domains for specific authenticated sessions.

Each domain has:

Its own subset of registered service names.
Its own set of policies controlling access and visibility.

All of these domains ultimately terminate in the same PID-1 launchd process, but they appear as distinct bootstrap ports and namespaces from the point of view of tasks.

The bootstrap port in practice

When a daemon is launched, it typically:

Receives a bootstrap port (for its domain) in its TASK_BOOTSTRAP_PORT.

Calls:

bootstrap_check_in(bootstrap_port,
                   "com.apple.locationd",
                   &service_port);

launchd receives this message on the appropriate domain’s bootstrap port and:
- Verifies, via the audit token, that the caller is the process associated with the job for "com.apple.locationd".
- Transfers the receive right for the pre-allocated service port into the daemon’s IPC space.

Client processes:

Use bootstrap_look_up() or xpc_connection_create_mach_service() on their bootstrap port.
launchd resolves the name in the caller’s domain and either:
- Returns a send right to the service port, or
- Fails with an error if the service does not exist or is not visible in that domain.

This mechanism:

Implements the lazy, on-demand launch of services.
Enforces which names exist and are reachable in each domain, with launchd as the central broker.

8.1.3 Parsing `launchd.plist` and the Binary Protocol for XPC Service Lookups

launchd’s configuration is driven by property lists (.plist) describing jobs, located under:

/System/Library/LaunchDaemons
/Library/LaunchDaemons
/System/Library/LaunchAgents
/Library/LaunchAgents
Per-user equivalents under ~/Library/LaunchAgents

At startup (and when configuration changes), launchd parses these plists once and compiles them into an internal data structure representing:

Jobs (labels, binaries, arguments, environments).
Their MachServices.
Their target domain (system/user/gui/login).
Policy metadata (KeepAlive, RunAtLoad, sockets, etc.).

The MachServices dictionary

A typical job might include:

<key>MachServices</key>
<dict>
    <key>com.apple.securityd</key>
    <true/>
</dict>

This instructs launchd to:

Allocate a Mach receive right for "com.apple.securityd" when loading the job.
Hold that right until:
- A client first looks up "com.apple.securityd", and
- The job has started and checked in.

launchd remembers:

The mapping "com.apple.securityd" → (job, receive-right).
Which domain that name belongs to.

Demand launching (lazy activation)

The common path for a client is:

The client calls:

xpc_connection_t conn =
    xpc_connection_create_mach_service("com.apple.securityd",
                                       dispatch_get_main_queue(),
                                       0);

libxpc sends a message to the caller’s bootstrap port asking for "com.apple.securityd".
launchd:
- Looks up "com.apple.securityd" in the caller’s domain.
- If the job is not running:
  - Spawns the configured binary via posix_spawn.
- Waits for the daemon to call bootstrap_check_in().
When the daemon calls bootstrap_check_in():
- launchd confirms the caller matches the job.
- Transfers the receive right for the service port into the daemon’s IPC space.
- Returns a send right to the client.

From the client’s perspective, the detail is hidden: it just sees an XPC connection that becomes ready.

Binary protocols: MIG vs XPC

Historically:

launchd exposed a MIG-based API defined in bootstrap.defs, including:
- bootstrap_look_up
- bootstrap_check_in
- bootstrap_create_server
These are still present and supported.

Modern userland prefers XPC, which:

Packages requests into binary dictionaries and sends them over Mach ports.
Allows richer types (arrays, dictionaries, file descriptors, additional Mach ports) to be transported in a structured way.

Inside launchd:

A central Mach receive loop demultiplexes incoming messages:
- MIG messages (identified by the Mach message ID) are routed to autogenerated handlers from bootstrap.defs.
- XPC messages (identified by XPC magic/version fields in the payload) are parsed into XPC objects and dispatched to XPC-specific handlers (job control, service lookup, status queries).

Domain-aware policy

On Tahoe-era systems, the bootstrap namespace is also used as a policy boundary:

The kernel attaches an audit token to each Mach message, including:
- PID, UID, GID, ASID, and other identity information.
launchd inspects:
- The audit token.
- The caller’s entitlements and sandbox profile (when available).
It enforces constraints such as:
- Only processes with appropriate mach-lookup entitlements can resolve certain global services.
- Sandboxed apps see only a restricted subset of services in their effective bootstrap domain.

In other words:

The bootstrap namespace is not just a map from string to port.
It is also a filter, with launchd acting as the enforcement point that decides which ports a given client is even allowed to know exist.

8.2 The Dynamic Linker (`dyld`)

If launchd is the architect of the userland process hierarchy, dyld (the dynamic linker) is the component that materializes each process image. In the macOS ecosystem, dyld is not merely a library loader; it is a privileged extension of the kernel’s execution model, responsible for:

Loading the main executable and its dependent images.
Enforcing Library Validation policies.
Applying Address Space Layout Randomization (ASLR).
On arm64e, integrating with Pointer Authentication (PAC).

On Apple Silicon and in the Tahoe architecture, dyld has been heavily reworked. Legacy rebasing mechanisms have been replaced with Chained Fixups to enable page-in linking, and dyld’s decisions are tightly coupled with the kernel’s memory management, which itself is constrained by the Secure Page Table Monitor (SPTM).

8.2.1 Mapping the Dyld Shared Cache (DSC)

The Dyld Shared Cache (DSC) is a defining feature of the macOS userland memory layout. It is a massive, pre-linked binary (often >4 GiB) that merges the text and data segments of most system frameworks (CoreFoundation, libSystem, Foundation, etc.).

The Shared Region:

To optimize memory and TLB usage, the kernel reserves a Shared Region in every process:

On arm64, this region typically begins at a high canonical address (e.g., around 0x180000000 in current releases).
The DSC is mapped into this region, and the backing physical pages are shared across all processes.

To satisfy W^X and fine-grained data protection, the DSC is split into multiple mappings:

__TEXT (RX):
Immutable code and constant data that must never be written at runtime.
__DATA_CONST (RO):
Read-only data that can be pre-relocated at build time and never changes at runtime (e.g., constant pointers, vtables).
__DATA_DIRTY (RW):
Data that must diverge per process (e.g., Objective-C class realization state, global variables).

The Tahoe/SPTM Constraint:

On Tahoe systems, the mapping of the DSC is mediated by SPTM:

Source from Cryptex:
The DSC binaries and associated metadata reside in the OS Cryptex, typically under:
```
/System/Cryptexes/OS/System/Library/dyld/
```
SPTM-Supervised Mapping:
When XNU initializes the shared region, it installs page tables for the DSC segments in each process’s address space. On SPTM-enabled systems:
- Each PTE change for DSC pages is vetted by SPTM.
- The physical frames backing __TEXT are associated with a “immutable code” state; once mapped, they are not permitted to transition to writable mappings under EL1 control alone.
Immutable Code under a Compromised Kernel:
Because SPTM operates at a higher privilege level than the kernel:
- Arbitrary EL1 writes cannot simply flip the DSC __TEXT pages to RWX.
- Any attempt to create new executable mappings for code that has not been validated by TXM can be blocked by SPTM when the Execute bit is requested.

Practically, this means traditional techniques that patch system libraries in-place from a kernel exploit are structurally constrained. Attackers must rely on indirection (e.g., hooks via __DATA_DIRTY, PLT-style trampolines, or userland injecting new, separately validated images) rather than overwriting shared-cache code directly.

8.2.2 RE Focus: Code Signature Validation (`fcntl(F_ADDFILESIGS)`) and the Call to TXM

dyld is the primary enforcer of Library Validation for userland. The OS policy is:

A process can only execute code that has been validated by the platform’s code-signing machinery, and for hardened processes, only from binaries signed by Apple or by the same Team ID as the main executable.

When dyld loads a Mach-O image, either during initial process launch or via dlopen, the high-level flow is:

mmap of the file:
The file is mapped into the address space with appropriate protections (typically at least readable, but not yet executable).
Signature Registration via F_ADDFILESIGS_RETURN:
dyld calls:
```
struct fsignatures fs;
fcntl(fd, F_ADDFILESIGS_RETURN, &fs);
```
The fsignatures_t structure informs the kernel where the code-signature blob (CMS) resides in the file and requests that this file be authorized for executable mappings.

On older architectures, the kernel (plus AMFI) parsed and validated the CMS blob in EL1. On Tahoe systems, validation is mediated by TXM, and enforcement by SPTM.

Conceptual Kernel → TXM Flow:

Marshalling:
The kernel identifies the physical frames that contain:
- The Mach-O Code Directory.
- The CMS code-signature blob.
Secure Monitor Invocation:
The kernel issues a secure call into TXM (e.g., via a GENTER-style transition), passing:
- References to those frames.
- Metadata for the code-signing request (team identifier, flags, platform binary vs third-party, etc.).
TXM Verification:
Inside TXM:
- The CMS blob is parsed and the signature chain is validated against:
  - The Static Trust Cache (for platform binaries shipped with the OS/Cryptexes), or
  - Apple’s CA hierarchy (for third-party code).
- Policy constraints are applied (e.g., hardened runtime flags, entitlements, revocation status).
Verdict and SPTM Tagging:
TXM returns a verdict to the kernel. If the code is accepted:
- SPTM is updated with metadata that associates the relevant CDHash and physical frames with a “blessed for execution” state.
Page-Fault-Time Enforcement:
When the process later executes into that image:
- The first access to a given code page triggers a page fault.
- The kernel attempts to install an executable PTE for that frame.
- SPTM intercepts the attempt and checks:
  - Whether the frame was previously “blessed” by TXM for this CDHash.
- If the check fails, the mapping is refused and the process is terminated (e.g., with SIGKILL | Code Signature Invalid).

The exact internal data structures and opcodes used between kernel, TXM, and SPTM are firmware implementation details. From the perspective of dyld, the observable behaviour is that F_ADDFILESIGS_RETURN can succeed or fail, and that executing unblessed code results in immediate termination, independent of kernel cooperation.

RE Tip:
When a process dies immediately after dlopen or after loading a plugin/framework, and dyld reports code-signature errors, the proximate userland symptom is often a failed fcntl(F_ADDFILESIGS_RETURN) or an immediate crash on first execution into the library. The authoritative reason (revoked certificate, missing trust-cache entry, policy violation) lives in TXM/SPTM logs and kernel log events, which may be partially redacted on production builds.

8.2.3 ASLR in Userland: Chained Fixups and the Death of `dyld_info`

Modern dyld (dyld 4.x and later) on Apple Silicon has effectively deprecated the legacy LC_DYLD_INFO rebasing/binding opcodes in favour of Chained Fixups (LC_DYLD_CHAINED_FIXUPS). This transition is not just a performance optimization; it is a fundamental change to how relocation metadata is encoded, tightly integrating ASLR and, on arm64e, PAC.

Limitations of Legacy Rebasing:

The previous model stored relocation metadata as a stream of opcodes (REBASE_OPCODE_DO_*, BIND_OPCODE_*) that described where in __DATA to add the ASLR slide and how to bind imports. At launch, dyld walked these opcode streams and:

Touched every page that contained a relocatable pointer.
Dirtying pages that might never be read, impacting both memory footprint and cache behaviour.

Chained Fixups: On-Disk Representation:

In the chained fixup model, on-disk “pointers” in the __DATA segments are actually encoded metadata. For each image:

LC_DYLD_CHAINED_FIXUPS points to a dyld_chained_fixups_header.
This header references a dyld_chained_starts_in_image structure, which contains:
- Per-segment start tables (dyld_chained_starts_in_segment), and
- For each participating segment, an array giving the offset of the first fixup in each 16 KiB page (or 0xFFFF if the page has none).

At each fixup location, the file contains a 64-bit encoded value such as dyld_chained_ptr_64_rebase or dyld_chained_ptr_arm64e:

A subset of bits encode:
- The next delta (in 4-byte units) to the next fixup in the same page.
- The target (either an offset into __TEXT for rebasing or an ordinal into the import table for binding).
- For arm64e, authentication flags and diversity bits.
A next value of 0 terminates the chain for that page.

Page-In Linking (Lazy Fixups):

With chained fixups, dyld no longer performs a global sweep at launch:

Initial Mapping:
The image is mapped into memory with its __TEXT and __DATA segments, but most __DATA pages have not yet been faulted in.
First Access / Page Fault:
When the process first reads or writes through a pointer in __DATA that resides on a page with chained fixups:
- A page fault is triggered.
- The kernel or a user-mode handler notes that this page has pending fixups.
Chain Walk:
The fixup logic:
- Consults the per-page start offset from dyld_chained_starts_in_image.
- Walks the chain by following next deltas until the chain terminates.
Applying Fixups:
For each encoded “pointer”:
- The target is interpreted as:
  - A __TEXT offset to be combined with the ASLR slide (for rebasing), or
  - An import ordinal resolved to a symbol address (for binding).
- On arm64e, the final pointer is authenticated:
  - PAC( Base + Offset, Key, Context/Discriminator ) is computed using process-specific PAC keys.
- The 64-bit metadata word on the page is overwritten with the final, signed, slid pointer.
After Fixup:
The page is now dirty (because the encoded metadata was overwritten), but only the pages that are actually accessed incur this cost.

PAC Integration (DYLD_CHAINED_PTR_ARM64E):

On arm64e, fixup entries use formats like DYLD_CHAINED_PTR_ARM64E and DYLD_CHAINED_PTR_ARM64E_AUTH_*:

Fields encode:
- Key selection (instruction/data key).
- Diversity bits (salt).
- Discriminator/context.
dyld computes PAC for each pointer at fixup time:
- Ensuring that:
  - The pointer is valid only under the current process’s PAC keys.
  - Attempts to transplant the pointer into another process or mutate the context bits will cause PAC failures at use.

ASLR and PAC are therefore coupled at the moment a page is faulted in and its fixups applied.

Reverse-Engineering Implications:

For reverse engineers, chained fixups fundamentally alter the static picture of binaries:

Raw on-disk __DATA segments no longer contain meaningful absolute pointers; they contain encoded metadata words.
Naive disassembly or CFG reconstruction that ignores chained fixups will see “garbage” addresses and broken callgraphs.
Correct analysis requires simulating dyld’s fixup engine to compute the final pointers.

Tooling must therefore:

Parse LC_DYLD_CHAINED_FIXUPS and the associated structs.
Walk chains on a per-page basis.
Optionally write a “de-chained” view of the file for analysis.

Examples:

ipsw dyld fixup and related tooling can emit a fixed-up view of Mach-O binaries extracted from DSCs.
Apple’s dyld_shared_cache_util (and its open-source analogues) can extract and apply fixups to DSC residents.
Recent versions of IDA Pro and Ghidra detect LC_DYLD_CHAINED_FIXUPS and apply fixups within the analysis database, even though the on-disk file remains in its chained form.

8.3 Cryptexes (Cryptographic Extensions)

The introduction of the Signed System Volume (SSV) in macOS Big Sur solved the problem of persistence: by anchoring the root filesystem in a cryptographic hash verified by iBoot, Apple ensured that the core OS partition is immutable. However, this immutability created an operational problem: patching a single high-level component (for example, dyld or WebKit) would require resealing and redistributing the entire SSV.

To resolve the tension between immutability and agility, Apple introduced Cryptexes (Cryptographic Extensions). A Cryptex is a cryptographically sealed, versioned filesystem image that can be mounted and “grafted” into the system hierarchy at boot or runtime. In the Tahoe architecture, Cryptexes are the primary mechanism for the Split OS design, decoupling the kernel/BSD and low-level system from rapidly evolving userland components.

8.3.1 The “Split OS” Architecture: `/System/Cryptexes/OS`

In modern macOS, the logical root filesystem (/) is effectively a skeleton:

it contains the sealed snapshot of the kernel and core boot artifacts on the SSV, and
it carries just enough structure to support bootstrapping.

The bulk of high-level userland—dyld, libSystem, system frameworks, many daemons—resides in the OS Cryptex.

The Image4 Container

A Cryptex is distributed as an Image4 (img4) container:

Payload (IM4P):
A disk image (typically APFS) containing a filesystem hierarchy.
Manifest (IM4M):
A signed metadata blob that binds the payload to Apple’s root keys. For some Cryptexes, the manifest can be personalized (tied to ECID, board, and security domain), preventing naive replay of mismatched OS components onto other devices.

Mounting and Grafting

Cryptexes are not mounted via a user-visible mount(2) call. They are integrated into the system by early boot code and the APFS driver:

Kernel bootstrapping:
While iBoot verifies and loads the Boot Kernel Collection (which uses Cryptex architecture), the Userland “OS Cryptex” (containing dyld and frameworks) is typically located, verified, and mounted by the Kernel and Trusted Execution Monitor (TXM) during the kernel bootstrapping phase, rather than directly by iBoot.
Trust cache extraction:
Inside the Cryptex, a binary trust cache (for example, wrapper/trustcache) lists CDHashes for all executable content in that Cryptex.
TXM ingestion:
Before the filesystem is grafted, this trust cache is provided to TXM. TXM verifies its signature and, on success, merges the hashes into the platform’s Static Trust Cache for that boot.
APFS grafting / firmlinks:
The APFS driver performs a graft operation that logically attaches the Cryptex under:
```
/System/Cryptexes/OS
```
and uses firmlinks or equivalent redirections so that paths like:
```
/usr/lib/libSystem.B.dylib
/System/Library/Frameworks/CoreFoundation.framework/...
```
are transparently resolved into the OS Cryptex, even though the SSV copy of /usr and /System/Library is skeletal.

From a reverse-engineering perspective, the “real” binaries of interest (current dyld, system frameworks, many daemons) live under /System/Cryptexes/OS/.... Paths under /System/Library or /usr/lib may be firmlinked views pointing back into this Cryptex.

8.3.2 Rapid Security Response (RSR): Patching via Overlay Cryptexes

The Cryptex mechanism enables Rapid Security Response (RSR): security updates that patch critical userland components residing in the OS Cryptex (e.g., WebKit, dyld) without requiring a full OS update or resealing of the SSV. Updating the kernel itself (Boot Kernel Collection) via RSR is architecturally constrained and typically requires a full OS update, as RSRs function as overlays on the userland filesystem.

Patch Cryptexes

An RSR is delivered as an additional Cryptex:

it usually contains only the components that changed (for example, updated dyld shared caches or WebKit frameworks),
it ships with its own Image4 manifest and trust cache, validated similarly to the base OS Cryptex.

Overlay / Union Mounting

When an RSR is applied:

Staging (cryptexd):
The cryptexd daemon orchestrates download, local verification, and placement of the new Cryptex image (typically onto the Preboot volume), and updates boot policy so early boot components know it exists.
Verification and trust cache update:
During boot, the RSR Cryptex’s manifest is verified. Its embedded trust cache is ingested by TXM so that binaries from the RSR are eligible for execution.
Overlaying the OS Cryptex:
The kernel overlays the RSR Cryptex on top of the base OS Cryptex using a union-style strategy:
- if a path exists in the RSR Cryptex, that version takes precedence;
- otherwise, the VFS falls back to the underlying base OS Cryptex content.

The effective runtime view is:

SSV  +  OS Cryptex  +  (optional) RSR Cryptex overlay

with VFS and firmlink logic ensuring a coherent /System and /usr layout.

Reversibility and Failure Handling

RSRs are designed to be reversible:

Atomicity:
Boot policy ensures the system is either fully in “base OS” state or in “base OS + specific RSR overlay” state. Partial application is not supported.
Rollback:
If repeated boots under a given RSR Cryptex fail (for example, due to a regression), the boot chain can mark that RSR as inactive and revert to the base OS Cryptex on subsequent boots, without modifying the SSV.

Security and RE Implications

Replay resistance:
Because Cryptexes and their trust caches are verified via Image4 and TXM, replaying older Cryptexes or RSRs is constrained by the same personalization and policy rules as the base OS.
Persistence model:
RSRs live outside the SSV (typically on Preboot), but they remain in the verified boot chain via their manifests and trust caches.
Analysis workflow:
To understand an RSR, you extract the RSR Cryptex image from the update payload, mount it, and diff its contents against the base OS Cryptex. The semantic delta is “what the RSR changed.” The live system view is the union of SSV + base OS Cryptex + any active RSR overlays, subject to SPTM/TXM integrity constraints.

9.0 The Security Daemon Hierarchy

While the kernel and the hardware monitors (SPTM/TXM) enforce the immutable laws of the system physics (memory protections, page table integrity, executable mappings), the complex, mutable business logic of macOS security is delegated to a hierarchy of userland daemons. These daemons operate with high privileges, often holding special ports or entitlements that allow them to influence kernel policy. For the reverse engineer, these daemons represent the “Policy Engine” of the OS—and historically, the most fertile ground for logic bugs and sandbox escapes.

9.1 `amfid` (Apple Mobile File Integrity Daemon)

The Apple Mobile File Integrity Daemon (amfid) is the userland arbiter of code execution policy. While the TXM enforces code-execution policy and manages trust caches for platform binaries in the guarded world, it lacks the context to evaluate the complex web of third-party provisioning profiles, developer certificates, notarization state, and MDM constraints.

In the Tahoe architecture, amfid functions as the Policy Decision Point (PDP) for non-platform code, while the kernel and TXM act as the Policy Enforcement Points (PEP) that ultimately decide whether pages become executable.

9.1.1 The Interaction between `launchd`, the Kernel (MACF), and `amfid`

amfid does not poll for binaries; it is driven by the kernel via the Mandatory Access Control Framework (MACF) hooks in the AMFI/AppleMobileFileIntegrity path.

The Bootstrap Race

amfid is a critical system daemon launched by launchd early in the boot process. Because amfid is responsible for verifying signatures, it presents a bootstrap paradox: Who verifies amfid?

The Solution: amfid is a platform binary shipped as part of the system OS (delivered via the Signed System Volume and associated cryptexes). Its CDHash is included in the Static Trust Cache that iBoot hands to the kernel during early boot.
TXM / AMFI Verification: When launchd spawns amfid, the kernel’s AMFI path consults TXM against the static trust cache. The CDHash is present, so the secure-world policy engine blesses the mapping immediately. No userland upcall is required for amfid itself.

From this point onward, amfid becomes part of the trusted computing base: it is the userland process that encodes code-execution policy for everything that is not already covered by immutable trust caches.

The Verification Upcall (The “Slow Path”)

When a user launches a third-party application (for example, /Applications/Calculator.app), the flow traverses the boundary between kernel and userland multiple times.

The Hook

The kernel executes execve. Along the AMFI path, the MACF hook mpo_vnode_check_signature in AppleMobileFileIntegrity is triggered. This hook is the choke point where the system decides whether the binary’s code signature is acceptable.
TXM / Trust Cache Miss

The kernel (via AMFI) queries TXM in the guarded world (conceptually via an internal “GENTER”-style call). TXM consults the Static Trust Cache and the Dynamic Trust Cache.

For a newly launched, third-party app whose CDHash has never been seen before, this lookup fails: there is no matching entry in either cache.
The Upcall

On a trust-cache miss, the kernel must delegate policy to userland. It constructs a Mach message targeting the HOST_AMFID_PORT (host special port 18), which is bound to amfid.

The message carries:
- A send right to a fileport for the executable.
- Metadata describing offsets and sizes (location of the code signature blob, file length, etc.).
- The CDHash or code directory parameters needed for verification.
Exact field layouts vary by OS release, but the kernel avoids trusting raw string paths where possible and instead relies on fileports and offsets.
amfid Processing

amfid receives the MACH IPC and performs the heavy lifting:
- Parses the CMS / code signature blob from the file.
- Validates the certificate chain via libmis.dylib (Mobile Installation Service) and often IPC to trustd.
- Extracts entitlements and, if present, an embedded provisioning profile (embedded.mobileprovision).
- Applies policy derived from Developer Mode, MDM profiles, and local configuration.
The Verdict

amfid responds to the kernel with a MIG reply corresponding to the verify_code_directory routine. For the kernel, this effectively collapses to:
- A status code (success, profile mismatch, expired certificate, etc.).
- Derived flags (e.g. whether get-task-allow is permitted).
- Optionally, additional hints for AMFI.
At this stage, the kernel updates the process’s cs_flags (Code Signing Flags), including bits such as CS_GET_TASK_ALLOW and CS_HARD, based on amfid’s verdict.
TXM Update

If amfid approves the binary, the kernel performs a second secure-world interaction: the CDHash and relevant metadata are added to the Dynamic Trust Cache managed under TXM’s control. Future launches of the same, unchanged binary can now be satisfied entirely in TXM and AMFI without repeating the upcall.
- Security Note: In Tahoe, the architecture is such that TXM remains the final authority on cryptographic validity. Even if the kernel or amfid were compromised, adding a CDHash to the dynamic trust cache requires passing TXM’s guardrails. amfid supplies the policy decision (“this developer identity / profile is acceptable here”), while TXM ensures that the code bytes actually match the identity being whitelisted.

RE Focus: The MIG Interface

The communication interface is defined in the (reverse-engineered) MIG definition usually referred to as mfi_server.defs. The key routine is often named verify_code_directory.

Input (conceptual): audit_token_t for the caller (kernel), mach_port_t file_port, offset and size parameters for the code signature, and flags controlling the verification mode.
Attack Surface: Historically, malformed Mach messages to amfid’s service port produced classic parsing bugs. Modern macOS hardens this by:
- Validating the audit token to ensure calls originate from kernel_task, not arbitrary userland.
- Tightening the MIG server and argument validation paths.
- Relying increasingly on fileports rather than untrusted string paths.

For reverse engineers, the MIG stubs and their error-handling paths remain prime targets for logic bugs and subtle policy bypasses.

9.1.2 Validating Code Directories (CDHash), Entitlements, and Provisioning Profiles

The core logic of amfid resides in its ability to connect a binary’s Code Directory (CD) to a valid certificate chain and, when applicable, a Provisioning Profile. This mechanism enforces both the iOS-style “Walled Garden” and the macOS notarization regime.

The Validation Logic (MISValidateSignatureAndCopyInfo)

amfid links against libmis.dylib, which exports the symbol MISValidateSignatureAndCopyInfo. This function encapsulates most of the signature and profile evaluation:

CDHash Extraction

amfid reads the LC_CODE_SIGNATURE load command, locates the Code Directory, and computes the CDHash by hashing the slots specified by the Code Directory (typically a truncated SHA-256 or SHA-1, depending on platform and epoch).
Entitlement Extraction

It parses the embedded entitlements plist from the signature blob. These entitlements express requested capabilities (e.g. com.apple.security.network.client, com.apple.security.get-task-allow, private IOKit entitlements).
Profile Correlation (Developer-Signed Binaries)

When the binary is signed by a non-Apple certificate:
- It looks for an embedded provisioning profile (embedded.mobileprovision).
- It verifies the PKCS#7 signature of the profile, ensuring it is issued by Apple.
- It compares the entitlements in the binary against the Entitlements dictionary in the profile, enforcing that the binary does not claim more than the profile grants.
- For development profiles, it verifies that the device’s identifier (UDID / platform identifier) is present in the ProvisionedDevices array (or matches the profile’s “All Devices” semantics, depending on platform).
Constraint Enforcement
- Restricted Entitlements: Certain entitlements (for example, com.apple.private.security.no-sandbox, low-level IOKit and CSR overrides) are “restricted” and only grantable when the signature chain terminates in specific Apple internal CAs or special program certificates.
- amfid enforces this hierarchy by refusing binaries whose entitlements exceed what the provisioning profile and certificate chain permit.

The “Union” of Trust: Notarization and Gatekeeper

On macOS, this signature evaluation interacts with the notarization system, primarily implemented in syspolicyd:

At download or first execution, Gatekeeper and syspolicyd evaluate notarization tickets (stapled to the binary or stored under /var/db/SystemPolicy*) and decide whether the binary is admissible under current policy.
Once a binary is admitted, subsequent executions still traverse AMFI/amfid:
- amfid ensures that the running code’s signature and entitlements still match what was originally notarized.
- It can treat notarized binaries as belonging to a higher trust tier compared to purely ad-hoc signatures (for example, relaxing some heuristics or additional scanning).

The effective trust decision is thus the intersection of:

Static trust caches and TXM policy (platform code).
Gatekeeper / notarization (admission control for untrusted downloads).
AMFI + amfid (per-execution verification and entitlement policy).

RE Focus: libmis.dylib Reversing

libmis.dylib is heavily stripped and obfuscated, but it has a simple, observable contract:

MISValidateSignatureAndCopyInfo returns an integer status, where 0 indicates success and non-zero error codes map to specific failures (profile expired, certificate invalid, entitlements mismatch, etc.).
amfid logs detailed failure reasons via os_log and friends. Many of these logs are visible only with specific boot arguments or developer configurations (for example, AMFI developer mode toggles).
Instrumenting the call sites and enumerating non-zero return codes is often the most efficient way to understand why a given binary is being killed or stripped of capabilities.

9.1.3 Exception Handling: How `get-task-allow` and Debugging Entitlements are Processed

One of amfid’s most security-sensitive roles is gating access to process debugging. The ability to attach a debugger (task_for_pid) is effectively a full compromise of the target process.

The get-task-allow Entitlement

In a standard production configuration, a process cannot be debugged unless either:

The system is in a special developer or recovery mode, or
The target process possesses the com.apple.security.get-task-allow entitlement and other policy conditions are satisfied.

Typical paths:

Xcode Builds: When an app is built and run from Xcode, the build system signs it with a development certificate and injects get-task-allow, allowing debugserver/lldb to obtain a task port.
App Store Builds: The App Store distribution pipeline strips get-task-allow before submission; resulting binaries are non-debuggable under normal policy.

The amfid Decision Matrix

During execve, the kernel extracts entitlements and passes them (directly or indirectly) into the AMFI/amfid path:

amfid validates that get-task-allow appears in both:
- The entitlements blob in the code signature.
- The entitlements and capabilities granted by the provisioning profile / certificate chain.

If the request is:

Valid: amfid indicates that CS_GET_TASK_ALLOW may be set in the process’s cs_flags. Subsequent task_for_pid checks can succeed (subject to further checks like caller UID, SIP bits, and TCC state).
Invalid or Over-Privileged: amfid can cause the entitlement to be ignored or the entire signature to be rejected, leading to kill-on-launch or a process without debug permissions.

The task_for_pid Check

When debugserver or lldb calls task_for_pid(target_pid):

The kernel checks the target’s cs_flags (including CS_GET_TASK_ALLOW) and applies additional policy (root privileges, SIP bits such as CSR_ALLOW_TASK_FOR_PID, and TCC automations).
If the flags and policy allow it, the caller receives a send right to the target’s task port; otherwise, the call fails (e.g. KERN_PROTECTION_FAILURE / KERN_FAILURE).

Developer Mode (The Tahoe Shift)

In the Tahoe architecture, the presence of get-task-allow and a development certificate is no longer sufficient by itself. Debuggability is additionally gated by Developer Mode:

State Check

Developer Mode state is maintained by LocalPolicy and enforced via SPTM/TXM. The AMFI/amfid path consults this state (via private interfaces and entitlements) when evaluating signatures.
Enforcement

If Developer Mode is disabled:
- Binaries signed solely with development certificates are generally treated as untrusted for execution and debugging on end-user systems.
- Even if the provisioning profile is otherwise valid, amfid and associated policy may refuse to honour get-task-allow, resulting in cs_flags that do not permit task_for_pid.

This prevents the trivial side-loading of a “debuggable” app to inspect memory on a locked-down device; enabling Developer Mode requires an explicit, TXM-mediated ceremony that materially lowers the device’s security posture.

Unrestricted Debugging, SIP, and AMFI

On macOS, System Integrity Protection (SIP) and AMFI are distinct but interacting mechanisms:

SIP (CSR Bits): SIP is configured via csrutil and boot arguments, setting bits such as CSR_ALLOW_TASK_FOR_PID (relaxing debugging restrictions), CSR_ALLOW_UNRESTRICTED_FS, and others.
AMFI / amfi_get_out_of_my_way: On internal or development builds, AMFI can be disabled or relaxed via boot-args (e.g. amfi_get_out_of_my_way=1), effectively causing the kernel to bypass code-signing enforcement.

Historically:

Setting debug CSR bits like CSR_ALLOW_TASK_FOR_PID allowed broader debugging of system processes, but did not by itself disable AMFI’s signature checks.
Disabling AMFI (amfi_get_out_of_my_way) is what effectively causes the kernel to treat code signatures as trivially acceptable.

In Tahoe:

SIP state is one of the inputs into LocalPolicy, with TXM enforcing the resulting policy at the page-table and executable-mapping level.
AMFI and amfid still perform signature and entitlement checks, but some CSR bits continue to relax specific restrictions (for example, attaching a debugger to processes that would otherwise be non-debuggable).
Fully “everything is valid” behaviour is reserved for tightly controlled developer or internal configurations and is not reachable on production systems without both SIP and AMFI being simultaneously subverted.

9.2 `sandboxd` & The Seatbelt Policy

If amfid is the bouncer checking identities at the door, the Seatbelt subsystem (marketed as App Sandbox) is the straightjacket applied once code is inside. Originating from TrustedBSD, the macOS sandbox is a Mandatory Access Control (MAC) mechanism that restricts a process’s access to resources—files, sockets, Mach ports, IOKit drivers—regardless of the user’s UID.

In the Tahoe architecture, the sandbox has evolved from a predominantly path-based filter into a semantic, metadata-driven enforcement layer, tightly coupled with the kernel’s VFS and process credential machinery and integrated with new Data Vault primitives.

9.2.1 Compiling SBPL (Sandbox Policy Language) to Bytecode

Sandbox profiles are expressed in SBPL (Sandbox Policy Language), a Scheme-like (LISP) dialect. The kernel does not interpret SBPL directly. Instead, policy is compiled into a compact bytecode format that the kernel executes.

The SBPL compiler lives primarily in libsandbox.dylib (and its libsystem glue), not in sandboxd.

The Compilation Pipeline

Profile Selection

Depending on the process, different profiles are selected:
- App Store Apps: The system applies a generic container profile that implements the standard app sandbox.
- System Daemons: Daemons specify their profile name in their launchd.plist (for example, com.apple.syslogd.sb), which is resolved to an SBPL specification.
- Platform Profile: In modern macOS, many core policies are consolidated into a Platform Profile bundled with Sandbox.kext / the Boot Kernel Collection. Individual SBPL files for system services still exist, but the trend is toward more policy being pre-compiled into the kernel cache to reduce runtime parsing and external configuration surface.
The Compiler (libsandbox / libsystem_sandbox)

When a process initializes the sandbox (for example, via sandbox_init_with_parameters):
- The call enters libsandbox.dylib in the process address space.
- libsandbox parses the SBPL (often using an embedded TinyScheme derivative).
- It resolves variable expansions such as ${HOME}, ${TemporaryDirectory}, and environment-dependent paths.
- It compiles the SBPL rules into a proprietary bytecode representation.
sandboxd is not on this critical path. Its primary role is to receive violation reports and log denied operations; it is not the SBPL compiler.
The Bytecode Structure

The compiled blob is a serialized decision machine:
- Opcodes: Operations such as “match path”, “match pattern”, “check entitlement”, “allow”, “deny”, and conditional branching.
- Filters: Rules are arranged into decision trees or tries keyed by operation class and path prefix (for example, file operations grouped under /System, /Users).
This bytecode is opaque to userland: it is handed to the kernel via the __mac_syscall / sandbox-specific syscalls, where Sandbox.kext attaches it to the process’s MAC label.

RE Focus: Reversing the Binary Blob

The kernel receives the compiled profile via a MACF-specific syscall (e.g. __mac_syscall with SANDBOX_SET_PROFILE):

Extraction: The blob can be captured by:
- Hooking sandbox_init* / sandbox_compile_* inside libsandbox.
- Hooking sandbox_set_profile / __mac_syscall at the userland boundary.
- Extracting the label attached to the process in the kernel (kauth_cred_t → sandbox label).
Decompilation: Tools such as sbs (Sandbox Scrutinizer) or custom disassemblers lift the bytecode back into an SBPL-like intermediate representation.
Profile Validation: In Tahoe, the kernel performs sanity checks on the bytecode (bounds checks, instruction validity, loop constraints) before attaching it to a process. This reduces the risk that a malformed profile can hang or crash kernel threads.

9.2.2 The Sandbox Kernel Extension: Hooking Syscalls via the MAC Framework

The enforcement engine is Sandbox.kext, which hooks into the XNU kernel via the Mandatory Access Control Framework (MACF).

MACF Hooks

XNU is instrumented with a large set of mac_ hooks placed at security-critical bottlenecks:

Filesystem: mac_vnode_check_open, mac_vnode_check_rename, mac_vnode_check_unlink, etc.
IPC: mac_mach_port_check_send, mac_mach_port_check_receive.
IOKit: mac_iokit_check_open, mac_iokit_check_get_property.

Sandbox.kext registers a MAC policy via a mac_policy_conf structure whose function pointers implement these hooks.

The Evaluation Flow

Trigger

A sandboxed process issues a syscall, for example:

open("/etc/passwd", O_RDONLY);
MACF Hook

The kernel executes mac_vnode_check_open. MACF dispatches this call to all registered policies, including Sandbox.kext.
Policy Dispatch

Sandbox.kext:
- Looks up the process’s kauth_cred_t.
- Retrieves the sandbox label, which includes a pointer to the compiled profile bytecode.
- Normalizes arguments (operation kind, path, vnode type, etc.) into a canonical form.
Bytecode Evaluation

The sandbox engine executes the profile bytecode:
- Input: Operation (for example, file-read), resource (path /etc/passwd), additional attributes (file type, vnode flags).
- Logic: Traverses the pre-compiled decision tree, checking path prefixes, patterns, and entitlements.
Caching (Performance Critical Path)

Evaluating bytecode on every syscall would be prohibitively expensive, so Sandbox.kext maintains caches:
- Per-vnode caches: Attach allow/deny decisions to vnode labels once a decision has been made.
- Per-process caches: Cache repeated deny decisions for patterns known to be disallowed.
Subsequent accesses to the same file or resource often bypass the full bytecode interpreter and reuse cached verdicts.
- RE Vulnerability: Bugs in cache invalidation (for example, renames, mount points, or attribute changes that fail to invalidate cached decisions) can lead to enforcement bypasses where the sandbox decision no longer reflects reality.

The Tahoe / SPTM Intersection

While sandbox policy is defined in software, the integrity of the enforcement hooks is backed by hardware:

The mac_policy_conf structures and many related function pointer tables reside in const segments (__DATA_CONST/__CONST) in the Boot Kernel Collection.
SPTM/TXM enforce invariants on the kernel’s page tables, preventing EL1 code from remapping those const segments as writable, even under a kernel write primitive.

This has two consequences:

Classical rootkits that “unhook” sandbox enforcement by overwriting function pointers in mac_policy_conf are blocked at the page-table level: the attempted store either faults or writes to a non-effective alias.
The sandbox policy can still be subverted through more subtle means (policy loading, profile compilation, credential forgery), but transparent pointer overwrites of core hooks are no longer a viable attack on Tahoe-class hardware.

9.2.3 Containerization: Data Vaults and Group Containers

In the Tahoe era, Apple has moved beyond simple path-based rules (fragile and prone to symlink and mountpoint attacks) toward semantic containerization of data.

Data Vaults

Data Vaults are used to protect the most sensitive data at rest—for example, Messages, Photos, and certain system databases.

Implementation: A Data Vault is typically a directory or volume flagged with specific VFS attributes (for example, the “datavault” flag and associated extended attributes).
Enforcement:
- Access decisions are made in MAC hooks before classic Discretionary Access Control (DAC). Even root (UID 0) cannot trivially ls or cat a Data Vault.
- Access is granted only if the calling process holds specific, private entitlements (for example, com.apple.private.security.storage.AppDataVault or service-specific variants).
The “Root” Fallacy: Running as root with host_priv is no longer sufficient. Data Vault checks are keyed off entitlements and sandbox state, not UID.
RE Focus: Kernel symbols such as rootless_check_datavault_flag and related helpers encode these checks. Reversing them reveals:
- How Data Vault flags are stored in the vnode and mount structures.
- Which entitlements are accepted for a given vault class.

Group Containers

To support IPC and data sharing between apps and their extensions (for example, a Widget and its host app), the sandbox introduces Group Containers.

The application-group Entitlement: Declares group IDs such as group.com.example.app. These IDs define shared container namespaces.
Container Manager: The system daemon containermanagerd manages the lifecycle and filesystem layout of these group directories (typically under ~/Library/Group Containers/).
Sandbox Logic:
- When compiling the app’s sandbox profile, libsandbox inspects entitlements.
- For each application-group identifier, it injects rules that allow controlled read/write access to ${HOME}/Library/Group Containers/<group-id>.
- This binds filesystem access directly to the cryptographic identity of the executable: only code signed with a matching App Group entitlement can enter that directory.

For the reverse engineer, group containers provide a clear mapping from entitlements → filesystem layout; group container IDs found in entitlements can be used to locate shared state and attack surfaces.

9.3 `tccd` (Transparency, Consent, and Control)

If amfid validates code identity and sandboxd/Seatbelt constrain code reach, tccd governs the most volatile part of the security model: user consent.

The Transparency, Consent, and Control (TCC) subsystem is effectively a “User Intent Oracle”. It governs access to privacy-sensitive sensors (Camera, Microphone), personal data (Contacts, Calendars, Photos), and privileged capabilities (Full Disk Access, Screen Recording). In the Tahoe architecture, tccd has evolved from a simple “prompt and remember” component into a complex attribution engine that must defend against consent hijacking and attribution spoofing.

9.3.1 The TCC Database: Schema, Integrity, and SIP

TCC persists user consent state in SQLite databases. There is a split between system-wide and per-user state:

System TCC: /Library/Application Support/com.apple.TCC/TCC.db — root-owned, stores system-wide decisions such as Full Disk Access.
User TCC: ~/Library/Application Support/com.apple.TCC/TCC.db — user-owned, stores per-user decisions such as Camera/Microphone access.

The Schema

The core table is access. For reverse engineering, key columns include:

service: Identifies the privilege (e.g. kTCCServiceSystemPolicyAllFiles, kTCCServiceMicrophone, kTCCServiceScreenCapture).
client: The bundle identifier or absolute path of the client.
client_type: Indicates whether client is interpreted as a bundle ID (0) or path (1).
auth_value: Encodes the decision (e.g. 0 = Denied, 1 = Unknown / Prompt, 2 = Allowed, 3 = Limited).
csreq: A compiled Code Signing Requirement (CSReq) used to bind the decision to a particular identity, not just a path string.

Additional columns (timestamps, indirect attribution fields, categories) vary by OS release, but these fields form the stable core.

The csreq Blob: Cryptographic Anchor

TCC does not trust filesystem paths alone. Instead:

When a request arrives, tccd obtains the process’s code signing information (via csops or similar APIs).
It evaluates whether the current code signature satisfies the stored csreq expression from the database row:
```
(Current_Code_Signature) satisfies (Stored_CSReq)
```
If the check fails (for example, the app was re-signed with a different certificate), existing permissions do not apply, and a new prompt may be triggered or access denied.

This prevents an attacker from overwriting /Applications/TrustedApp.app with malware and inheriting its camera or disk permissions.

Protection Mechanisms

Although the TCC databases are ordinary SQLite files, access to them is tightly controlled:

SIP Protection: The system TCC database is protected by SIP; direct modifications are blocked for all but a handful of Apple-signed components with special entitlements (including tccd itself).
MAC / Data Vaults: On newer macOS versions, the directory containing TCC databases can be part of a Data Vault, requiring specific entitlements just to traverse or open the directory and files.
Exclusive Control by tccd:
- tccd maintains long-lived connections and can hold locks on the database.
- Attempts to modify the file on disk directly (for example, via sqlite3 under a disabled SIP configuration) often lead to integrity check failures, after which tccd may restore the database from a backup or recover via WAL semantics.

RE Focus: The tccutil Fallacy

The tccutil command-line utility behaves as a client of TCC, not a raw database editor:

It communicates with tccd via XPC to request resets or clears.
It does not write to TCC.db directly.

For reverse engineering:

Observing XPC traffic between tccutil and tccd yields the supported operations and their internal names.
Direct tampering with TCC.db is fragile and often counterproductive; intercepting or simulating tccd’s own XPC interfaces is more robust.

9.3.2 The Attribution Chain: Determining Who Is Asking

The hardest problem TCC solves is Attribution. When an action flows through multiple processes, which one should be considered the “client” for consent purposes?

Examples:

A GUI app that launches a helper tool to touch the camera.
A terminal running a shell script that launches curl or a Python interpreter.
A background agent performing work on behalf of a signed, user-facing app.

The XPC Audit Token

When a message arrives at tccd (for example, over com.apple.tccd.system or com.apple.tccd):

The Mach message carries an audit token in its trailer.
tccd extracts PID, UID, GID, and audit attributes from this token.
It uses the kernel’s code-signing interfaces (csops, CS_VALID flags) to resolve the token to an actual, signed binary on disk.

The audit token is provided by the kernel and cannot be forged by userland, making it the primary identity anchor.

The “Responsible Process” Problem

Attribution is not always identical to the immediate caller:

For Terminal.app running curl, the responsible entity for a network or disk access may be considered Terminal.app, not curl.
For automation or helper tools, a background daemon might act on behalf of a user-facing app.

To handle this, TCC models an Attribution Chain:

responsible_pid and Relationship Tracking
- Launch services, XPC, and higher-level frameworks can mark another process as the “responsible” one (for example, via launch configuration or XPC flags).
- tccd verifies that the relationship between caller and responsible process is legitimate (parent–child, session, or entitlement-based).
Access Object Construction

Internally, tccd constructs a conceptual TCCAccessRequest:
- Subject: The process issuing the request (the immediate caller).
- Accessor: The process that will actually interact with the resource (often equal to the subject).
- Attributor: The process that should be presented to the user in UI and used as the key in the database.
Decision Logic

Roughly:
- If the caller has a private entitlement such as com.apple.private.tcc.allow for the requested service, access is granted without user interaction.
- Otherwise, TCC looks for an existing row in TCC.db for the attributor and service (using csreq matching).
- If no row exists, tccd triggers a user prompt.

Secure UI

TCC prompts are not drawn by the requesting client:

tccd delegates UI to system agents such as UserNotificationCenter / CoreServicesUIAgent.
Prompts are shown in elevated WindowServer layers that the client cannot fully control or overlay, mitigating clickjacking and fake consent dialogs.

9.3.3 RE Focus: XPC Attacks against TCC Endpoint Validation

From a vulnerability research perspective, tccd is a high-value target. Gaining the ability to impersonate a trusted client (such as Finder.app) can yield Full Disk Access or other sensitive capabilities.

Attack Vector 1: XPC Injection into Trusted Clients

Many TCC-permitted apps are extensible:

They load bundles or plugins via dlopen.
They may allow scripting or untrusted content with code execution.

If an attacker injects code into such a process:

That code runs inside the trusted PID.
TCC continues to see the trusted app’s identity and grants access based on its existing permissions.

Mitigations:

Hardened Runtime and Library Validation (enforced by AMFI and dyld in cooperation with TXM) prevent loading unsigned or unentitled libraries into hardened processes.
However, any app with com.apple.security.cs.disable-library-validation or similar entitlements remains a potential carrier for this class of attack.

Attack Vector 2: Fake Attributors and XPC Payload Spoofing

Earlier macOS versions were more trusting of client-supplied metadata in XPC messages:

Some TCC code paths accepted an explicit “target token” or attribution fields from the client’s XPC dictionary.
Attackers could attempt to supply a forged target_token that pointed to a more privileged app.

Modern TCC has hardened this:

For most services, tccd ignores user-provided tokens in XPC payloads.
It trusts only the kernel-supplied audit token from the Mach message trailer and reconstructs attribution from kernel state and entitlement checks.

Attack Vector 3: Semantic Confusion via Automation (AppleEvents, open, etc.)

An attacker can attempt to coerce a privileged app into performing an action:

For example, using AppleEvents or the open command to cause Terminal or another privileged app to run a script or open a sensitive file.
If the privileged app is the attributor in TCC’s view, its permissions are leveraged by the attacker’s payload.

Mitigations:

Automation permissions such as kTCCServiceAppleEvents gate which apps can send AppleEvents to which targets.
tccd tracks automation relationships and often requires separate consent for one app to control another.

The Tahoe Impact: Hardware-Anchored Identity

On Apple Silicon with Tahoe-class hardware:

TCC depends on code-signing identity and hardened runtime flags obtained from the kernel.
Those, in turn, are anchored in TXM and SPTM:
- TXM controls executable mappings and trust caches.
- SPTM enforces that the kernel’s view of code identity cannot be arbitrarily rewritten via page-table manipulation.

Consequences:

A kernel attacker who sets CS_VALID bits in process credentials without correspondingly convincing TXM risks creating a state where pages will not be executable or are killed on use.
TCC’s reliance on code identity is therefore backed by a hardware root of trust: subtly altering TCC decisions still requires either:
- Subverting tccd’s logic (via XPC or parsing bugs), or
- Subverting the TXM/SPTM path that defines which CDHashes are trustworthy.

Even under kernel compromise, forging the identity of a high-value system binary that TCC trusts is significantly more complex than on pre-SPTM systems; the identity must be consistent from the userland view, the kernel’s credentials, and the secure-world trust caches.

10.0 User Session, Authentication & Data Protection

The transition from the system bootstrap phase to the interactive user session represents a critical boundary crossing. Up to this point, the system has operated primarily in the Startup domain, managed by the root launchd context. The instantiation of a user session requires the creation of a new security context—the Audit Session—and the decryption of user-specific cryptographic material anchored in the Secure Enclave.

In the Tahoe architecture, this process is no longer a simple comparison of a password hash against a file. It is a hardware-mediated ceremony involving:

Evaluation of the user’s credentials via Open Directory and the Shadow Hash store.
Unlocking of a SEP-protected per-user secret that underpins the Secure Token / FileVault authorization model.
Derivation or unwrapping of the User Keybag inside the SEP.
Establishment of a local Kerberos identity (via the Local KDC / LKDC) for those services that participate in single sign-on, with the initial credentials ultimately rooted in secrets that are only accessible after the SEP has accepted the login.

Biometrics (Touch ID, Face ID, Optic ID) do not replace the password; they conditionally authorize the Secure Enclave to perform cryptographic operations—such as unwrapping key material—that would otherwise require manual secret entry.

10.1 `loginwindow` & `opendirectoryd`

The graphical login experience is orchestrated by two primary userland components:

loginwindow – Manages the session lifecycle and login UI, coordinates shield windows, and drives the state machine for login / logout / fast user switching.
opendirectoryd – Provides the abstraction layer for authentication and identity services, loading plugins to speak to local, LDAP, and Active Directory nodes.

Both components have lineage back to NeXTSTEP, but their internals have been aggressively refactored to support the hardware-backed security model of Apple Silicon and the Tahoe boot chain.

10.1.1 The Audit Session ID (ASID) and Kernel Tracking

In XNU, the concept of a “User” in the sense of a login instance is tracked via the Audit Session ID (ASID). This is distinct from the UNIX UID/GID:

UID/GID – Identify principals in the traditional POSIX sense.
ASID – Identifies a specific authenticated session (e.g. physical console login, fast user switch slot, SSH login, screen sharing session).

Every process in the system carries an audit_token_t which encodes, among other fields, the ASID of the session under which it is running.

The setaudit_addr syscall

When loginwindow successfully authenticates a user, it does not simply setuid. It calls into the BSM audit stack via the setaudit_addr syscall (typically through libbsm wrappers):

Kernel structure: The syscall populates the auditinfo_addr state, from which audit_token_t values are derived for that process.
Inheritance: Children inherit their parent’s ASID in much the same way they inherit UID/GID.
Mutability constraints: Changing an ASID after it has been established is tightly controlled. In practice, only a small set of privileged components (e.g. loginwindow, sshd) can create or reassign audit sessions, and they do so under private entitlements discovered via reverse engineering rather than public API.

For almost all processes, the ASID behaves as a write-once attribute: it is set when the session is created and then propagated down the process tree.

ASID as a Console Ownership signal

The ASID acts as a primary signal for “Console Ownership” in several subsystems:

TCC / tccd:
Access-control decisions for sensors such as Camera and Microphone are made in the context of an audit token. When a process requests, for example, Camera access, tccd evaluates whether the request comes from the ASID associated with the active graphical console. Foreground sessions see prompts; non-console sessions (e.g. SSH) are generally denied or handled differently.
WindowServer / SkyLight:
Only processes that belong to the active console ASID are permitted to establish the full, interactive connection to the WindowServer required to draw on the screen. Other ASIDs may be confined to offscreen rendering, remote sessions, or be blocked entirely.

This makes the ASID a crucial anchor for reasoning about which processes are “actually in front of the user” in the Tahoe user-session model.

RE Focus: security_authtrampoline and launchd domains

Historically, the transition from the loginwindow context (running as root) to the user context involved a setuid helper binary, security_authtrampoline, which mediated the handoff of credentials and environment to a per-user /sbin/launchd process. That design existed in earlier OS X releases.

Modern macOS (including Tahoe) uses a hierarchical model:

There is a system launchd process (PID 1) for the entire system.
Additionally, modern macOS spawns separate, per-user launchd processes to manage user-specific sessions and agents.
launchd manages multiple domains in its bootstrap namespace:
- A system domain for LaunchDaemons.
- User domains keyed by UID (e.g. user/501/).
- Login/session domains keyed by ASID (e.g. login/ASID/ or session/ASID/).
- GUI domains (e.g. gui/UID/) that correspond to interactive consoles.

On successful authentication, loginwindow now:

Uses private XPC/session APIs (e.g. xpc_session_create and related calls, as observed via reverse engineering) to facilitate the creation of a per-user launchd instance which manages:
- A user domain for the authenticated UID.
- A login/session domain keyed by the newly established ASID.
Binds that login domain to the new Audit Session:
- New user processes launched for the session are started under this per-user launchd.
- Their audit_token_t values reflect both the user’s UID and the new ASID.

From this point of view:

The per-user launchd becomes the logical root of the user’s process tree for that session (services, agents, apps).
While ultimately bootstrapped by the system, these processes are managed by the distinct per-user launchd entity rather than existing solely as domains inside the global PID 1 launchd.

For reverse engineers, the key observation points are:

Tracking how loginwindow transitions from “no session” to “new ASID + new login domain”.
Enumerating launchd jobs in the relevant user/ and login/ namespaces to reconstruct the user’s process lattice for a given ASID.

10.1.2 `loginwindow`: The Shield Window and Session State

loginwindow (at /System/Library/CoreServices/loginwindow.app/Contents/MacOS/loginwindow) is the session leader for the console. It:

Draws the login UI and lock screen.
Negotiates authentication with opendirectoryd and Kerberos components.
Manages fast user switching and logout.
Maintains the “Shield Window” that sits above all userland UI during sensitive phases.

The Shield Window (anti-overlay)

To prevent “fake login” and clickjacking attacks in which a malicious application draws a visually perfect imitation of the login screen to steal credentials, loginwindow uses a privileged connection to SkyLight (the WindowServer framework):

Window level: The login UI is drawn at or near kCGShieldingWindowLevel, a reserved Z-order used by the system for modalities like login, lock, and screen dimming overlays.
Exclusive event routing: While the Shield Window is active, the WindowServer routes all keyboard and pointer events exclusively to loginwindow. Background applications may still be composited but do not receive input, even if their windows visually overlap or mimic the login UI.
Console focus: The Shield Window is tied to the active console ASID, so remote or background sessions cannot legitimately persist a shield that captures events intended for the physical user.

For RE work, confirming input exclusivity via event taps is a good sanity check that the shielded state is active.

The State Machine

loginwindow implements a substantial state machine driven by:

AppleEvents: Legacy IPC paths that still orchestrate parts of the login / logout choreography and client notifications.
Darwin Notifications / XPC: Modern notification mechanisms for coordinating with opendirectoryd, launchd, and system services.

Relevant legacy hooks:

LoginHook / LogoutHook:
While officially deprecated, the underlying code paths remain. They are surrounded by modern sandboxing and hardened runtime checks, but they still provide observable transitions around session start / end.

Session state persistence:

Resume / Transparent App Lifecycle (TAL):
loginwindow participates in the “Resume” feature (re-opening windows after reboot or logout). State is persisted across:
- Per-host preferences such as ~/Library/Preferences/ByHost/com.apple.loginwindow.*.plist.
- Per-application saved state under ~/Library/Saved Application State/.
These artifacts are protected by the user’s Data Protection keys and provide a rich post-mortem surface for reconstructing session evolution.

10.1.3 `opendirectoryd`: The Authentication Broker

opendirectoryd is the daemon responsible for answering the question: “Are these credentials valid for this identity?” It is a modular daemon that loads plugins (bundles) to handle different directory services: local, LDAP, Active Directory, and more.

The Local Node (/Local/Default)

On a standalone Mac, authentication is handled by the Local Node, whose data store lives under:

/var/db/dslocal/nodes/Default/

Within this node:

Users are stored as individual property list (.plist) files under users/.
These plists contain metadata (name, UID, group memberships, secure token flags, etc.) but not directly the password hash.

Shadow Hash Data

The actual password verifier is stored as Shadow Hash data:

The user plist typically contains a ShadowHashData key whose value is a binary blob.
Analysis of these blobs shows:
- A SALTED-SHA512-PBKDF2 representation of the password for compatibility with older flows and offline verification scenarios.
- Additional structured fields used by Apple’s modern authentication path, including material that is only meaningful in combination with the Secure Enclave and device-specific secrets.

In the Tahoe-era architecture, it is useful to conceptually treat part of this blob as a SEP-wrapped per-user secret that participates in FileVault and keybag unlock. Apple does not publish the internal structure of ShadowHashData, but reverse engineering strongly indicates that the blob contains more than a conventional hash.

Verification Flow (ODRecordVerifyPassword)

When loginwindow submits a password to opendirectoryd for a local account, the flow roughly looks like this:

Directory lookup:
opendirectoryd uses its Local Node plugin to locate the user record and retrieve the associated ShadowHashData blob.
Hash verification:
The SALTED-SHA512-PBKDF2 component can be verified locally to confidently reject obviously wrong passwords without involving the SEP.
Secure Enclave mediation:
For FileVault-enabled accounts and for modern secure-token flows, opendirectoryd (via lower layers in the stack) invokes the AppleSEPKeyStore interface in the kernel:
- The candidate password and the relevant wrapped secret(s) derived from ShadowHashData are marshalled to the kernel.
- The kernel forwards this to the SEP over the mailbox channel.
- The SEP combines:
  - The device’s UID key (fused in hardware, never leaving the SEP).
  - A KDF over the password and salt.
  - Policy- and measurement-dependent state (e.g. SKP).
- The SEP attempts to “unwrap” the per-user secret and, if successful, signals success and may derive additional keys for keybag and FileVault operations.
Result propagation:
opendirectoryd treats SEP success as authoritative for those modern flows. A failure at this stage typically manifests as an authentication error even if the legacy PBKDF2 hash alone would have been satisfied.

RE Implication

This architecture has two important consequences:

Password hashes vs. device-bound keys:
Extracting ShadowHashData allows offline cracking of the PBKDF2-SHA512 password hash, but recovering the password does not by itself reconstruct the FileVault Volume Encryption Key (VEK) or class keys. Those require the SEP, UID key, and SKP-bound material.
Device specificity:
The secrets that actually unlock user data are bound to the specific Secure Enclave instance that created them. Moving Shadow Hash material to another Mac does not make that user’s FileVault-protected data decryptable without further compromise.

From a red-team perspective, this forces attacks toward live credential interception (before the password is sent into the verification pipeline) or SEP compromise, rather than traditional offline hash cracking for disk decryption.

10.1.4 Kerberos and the Local KDC (Heimdal)

Modern macOS systems ship with a Heimdal Kerberos stack and, by default, support a Local Key Distribution Center (LKDC). The LKDC provides Kerberized identities for local services and is integrated with Open Directory.

Why Kerberos on a standalone Mac?

Kerberos avoids passing plaintext passwords around systemwide. Instead:

Initial login (when Kerberos is configured):
Once the user’s credentials have been accepted (potentially via SEP-mediated verification), the system can obtain a Ticket Granting Ticket (TGT) from the LKDC corresponding to that account. This step is conditional: non-Kerberized setups or purely local workflows may omit it.
Credential cache:
Kerberos tickets are stored in a credential cache managed by the system (kernel and userland helpers), typically accessed via the standard KRB5CCNAME / CCAPI plumbing.
Service authentication:
When the user interacts with Kerberized services (e.g. Screen Sharing, some system preference panes, local file services, AD-backed services), the client obtains a service ticket from the LKDC and presents it to the target service instead of resending the password.
Validation:
Services validate the Kerberos ticket and enforce their own authorization logic.

Smart Card and PKINIT

In higher-assurance environments:

Smart cards or platform PIV tokens (backed by the Secure Enclave) are used instead of passwords.
Kerberos uses PKINIT to validate an X.509 certificate chain, mapping it to a Kerberos principal.
Tahoe’s hardened boot and driver model ensures that:
- The smart card driver stack (often running as a driver extension, dext) is validated and measured under TXM/LocalPolicy.
- Certificates and private keys used for PKINIT are only accessible after SEP policy checks.

RE Focus: Heimdal.framework

The private Heimdal.framework contains the glue between loginwindow, opendirectoryd, and the Kerberos stack:

Functions like krb5_get_init_creds_password remain useful RE chokepoints for observing when and how plaintext credentials are turned into Kerberos tickets.
Hooking these paths requires bypassing SIP and the hardened runtime and is therefore squarely in the “post-exploitation / lab” category rather than a practical on-disk modification target.

10.2 Biometric Unlock (Touch ID / Face ID / Optic ID)

Biometric authentication on Apple platforms is frequently misunderstood as a replacement for the passcode or password. Architecturally, it is a convenience mechanism:

Biometrics never replace the underlying secret; they authorize the Secure Enclave to perform a cryptographic operation that would otherwise require manual entry of that secret.
The SEP decides whether biometric factors are currently acceptable (policy, backoff, recent passcode use, secure intent).
On success, the SEP unlocks or derives specific keys and returns opaque handles or tokens to the OS.

In the Tahoe architecture, the biometric stack is an interplay between:

Userland daemons (coreauthd, biometrickitd).
Kernel drivers (AppleBiometricSensor, Local Authentication hooks).
The Secure Enclave.
For Face ID and Optic ID: the Secure Neural Engine (SNE).

10.2.1 The Daemon Hierarchy: `coreauthd` → `biometrickitd` → SEP

The implementation is split across two main daemons to enforce separation of concerns:

coreauthd – Policy
Located at
/System/Library/Frameworks/LocalAuthentication.framework/Support/coreauthd,
it implements the system’s Local Authentication policy engine:
- Manages LAContext instances and associates them with PIDs, ASIDs, and calling processes.
- Parses Keychain Access Control Lists (ACLs), evaluating requirements such as “biometry OR passcode” vs “biometry AND device unlock”.
- Implements the Access Control Module (ACM) logic that mirrors SEP-side decision structures: it constructs and validates the requests that will eventually be sent to the Secure Enclave.
biometrickitd – Mechanism
Located at /usr/libexec/biometrickitd, it manages the physical biometric sensors:
- Sensor abstraction: Loads device-specific plugins (e.g. Mesa for Touch ID, Pearl for Face ID, Jade for Optic ID).
- Power / state management: Controls sensor power, exposure, illumination hardware, and readiness.
- Data relay: Sets up shared buffers or DMA configurations between the sensor hardware and the Secure Enclave via the kernel. It does not perform high-level biometric matching; it shuttles encrypted sensor output toward the SEP.

The Handshake

A typical biometric request flows as follows:

An app invokes -[LAContext evaluatePolicy:localizedReason:reply:].
coreauthd:
- Validates the caller’s code signature, entitlements, and audit token (including ASID).
- Checks Keychain or system ACLs to decide whether biometry is acceptable for this operation.
- Creates an ACMContext structure representing this auth attempt.
coreauthd sends an XPC request to biometrickitd to arm the appropriate sensor.
biometrickitd:
- Issues IOConnectCall* requests into the biometric kernel driver (AppleBiometricSensor and relatives).
- The driver configures the sensor and a buffer that is shared with or visible to the Secure Enclave.
The kernel signals the SEP via the mailbox that a biometric capture session is ready and provides the buffer references.

At that point, the SEP takes over capture, matching, and decision logic; userland daemons observe state transitions and present UI, but never see raw biometric templates.

10.2.2 The Hardware Path: Sensor-to-SEP Pairing

A critical security property of the biometric stack is hardware pairing between the sensor module and the Secure Enclave.

Factory pairing

During manufacturing and repair-authorization procedures:

The biometric sensor module (Touch ID button, TrueDepth camera system, Optic ID array) and the SEP perform a pairing protocol.
A shared secret is established and stored:
- In the sensor’s controller.
- In SEP-managed internal storage (e.g. xART).

Encrypted channel

When a biometric capture occurs:

The sensor acquires raw data (fingerprint ridge map, IR depth map, iris texture).
The sensor hardware encrypts this data using an ephemeral session key—negotiated via the shared pairing secret—before putting it on the bus.
The encrypted payload travels over SPI/MIPI to the Application Processor.
The biometric kernel driver writes the encrypted blob into a region of memory that is readable by the SEP.
The SEP reads the blob, decrypts it using the session key, and performs all further processing internally.

From the AP’s perspective, these buffers contain high-entropy ciphertext. Dumping them from the kernel or an I/O trace yields no usable biometric image data.

RE Implication

Two empirically observable consequences:

Swapping a Touch ID or Face ID module between devices without running Apple’s pairing tools causes biometric functions to fail: the SEP can no longer decrypt sensor output.
Hooking the biometric driver stack and dumping in-flight data shows encrypted blobs rather than structured images, confirming that matching happens exclusively inside the SEP / SNE domain.

10.2.3 The Secure Neural Engine (SNE) & Optic ID

Face ID and Optic ID push biometric matching beyond the capabilities of the general-purpose SEP core. To handle these workloads, Apple partitions the Neural Engine (ANE) into:

A standard mode – accessible to userland via Core ML.
A secure mode – a slice reserved for the Secure Enclave, sometimes referred to as the Secure Neural Engine (SNE).

Optic ID Flow (Tahoe / Vision Pro)

At a high level, an Optic ID authentication proceeds as follows:

Capture:
The dedicated Optic ID cameras capture spatiotemporally modulated IR images of the user’s eyes.
Encrypted transfer:
As with Touch ID and Face ID, the raw frames are encrypted at the sensor and written as ciphertext into memory visible to the SEP.
SNE setup:
The SEP:
- Ensures that the portion of the Neural Engine allocated for secure use is scrubbed and placed under the control of its memory protection regime.
- Loads the Optic ID neural network model and associated parameters.
Feature extraction:
The SEP feeds the encrypted image data through the secure ANE slice:
- The SNE produces feature vectors representing the iris and surrounding structures.
Template matching:
The SEP compares the feature vector against stored templates in its Secure Storage Component (xART-backed), applying thresholds, quality checks, and policy (user presence, recent activity, etc.).
Liveness and Attention detection:
In parallel, the SEP uses the spatiotemporal pattern of IR illumination and pupil response to distinguish live tissue from static imagery or contact-lens attacks. In addition to spatiotemporal patterns, the SEP utilizes "Attention Aware" neural networks to verify gaze direction and eye openness, ensuring the user is alert and consenting.

Memory protection

On recent Apple Silicon generations:

The memory used for SEP-private and SEP–SNE-shared computations is protected by the Secure Enclave’s Memory Protection Engine.
Observers outside the SEP domain (including the AP and hypervisors) see encrypted and authenticated data when they attempt to read those regions.
This ensures that:
- Biometric templates and intermediate neural activations never appear in plaintext outside the Secure Enclave trust boundary.
- Dumping DRAM does not expose Optic ID templates or models in a directly usable form.

10.2.4 Secure Intent: The GPIO Hardline

For high-value transactions (Apple Pay, high-assurance key operations), Apple requires more than “biometric match.” Malware could, in principle, trick the user into satisfying a biometric prompt while a hidden transaction is in flight.

To address this, Apple implements Secure Intent as a physical side channel into the SEP.

The physical control

On supported devices:

The side/top/power button is wired not only to the Application Processor and Always-On Processor (AOP), but also via a dedicated signal path to the Secure Enclave.
This signal path allows the SEP to independently observe specific button gestures (e.g. double-click).

The logic

When a transaction is marked as requiring secure intent (via LocalAuthentication / Apple Pay policy):

The SEP performs the biometric match as usual.
On success, instead of immediately unwrapping or signing with the relevant key, the SEP:
- Records that a biometric match is pending for a secure-intent operation.
- Starts a short internal timer window.
The SEP monitors its dedicated button line for the required gesture (e.g. double-click within a given time bound).
Only if both conditions are satisfied:
- Recent acceptable biometric match.
- Correct physical button gesture within the window.
  does the SEP:
- Release the Apple Pay token.
- Unwrap or use the key required for the operation.

RE Focus

From an attacker’s perspective:

UI spoofing (e.g. drawing a fake “Double Click to Pay” overlay via WindowServer) cannot produce the electrical signal on the SEP’s dedicated line.
Even full compromise of the AP and WindowServer stack cannot bypass secure intent without either:
- Inducing the user to perform the real physical gesture at the right time, or
- Compromising the SEP itself.

10.2.5 The Local Authentication Context (LAC) and Token Binding

When authentication succeeds, the SEP does not simply return true / false. It returns or maintains cryptographic context that is later used to authorize specific operations.

ACMHandle and context

Internally, coreauthd and related components track an opaque handle (often modeled as an ACMHandle) associated with:

The LAContext created for the app.
The SEP’s record of:
- The factor that succeeded (passcode vs. biometry).
- The time of the auth.
- Relevant policy state (device lock state, secure intent, etc.).

This handle is then passed to other system components that need to prove “recent successful user presence” without re-prompting.

Keychain and token binding

For a Keychain item protected by kSecAccessControlUserPresence or a similar policy:

The client invokes a Keychain operation.
securityd (the Keychain daemon) verifies that it has a suitable ACMHandle or triggers coreauthd to obtain one.
securityd sends:
- The encrypted keyblob (wrapped key).
- The ACMHandle or equivalent context.
  to the SEP.
Inside the SEP:
- The handle is checked for validity and freshness (time bounds, lock state, backoff).
- If valid, the SEP uses its internal keys to unwrap the keyblob.
Depending on the item’s protection:
- The unwrapped key may be returned to securityd (for extractable keys).
- Or the SEP may perform the cryptographic operation internally (for non-extractable keys).

In all cases, the AP never gains the ability to “forge” recent user presence; it can only present handles that the SEP previously issued.

Backoff and retry policy

The SEP enforces retry and lockout policy in hardware:

Failed biometric attempts increment counters stored in SEP-protected storage (e.g. xART).
After a small number of failures, delays are introduced between attempts.
After a bounded number of failures (e.g. five for Face ID / Touch ID), biometric authentication is disabled until the user enters the passcode or password.
Time-based rules (such as requiring a passcode after a certain period since last unlock or since last passcode entry) are also enforced by SEP logic rather than the AP.

The exact thresholds and timing are encoded in sepOS and evolve across OS generations, but the important property is that they are not under kernel or userland control.

10.3 Data Protection & FileVault

On Intel Macs, FileVault was implemented as a distinct full-disk encryption layer (CoreStorage) that sat below the filesystem. On Apple Silicon, this layering has collapsed into a unified Data Protection model:

Every file on the APFS volume is encrypted with a per-file key.
Per-file keys are wrapped by class keys.
Class keys are stored in keybags that are managed by the Secure Enclave.
“Turning on FileVault” primarily changes how the Volume Encryption Key (VEK) is protected: from “effectively UID-only” to “UID plus user secret (password) and system measurement (SKP).”

In macOS Tahoe, the Data Protection model from iOS is carried over almost verbatim and extended with Mac-specific SKP and policy machinery.

10.3.1 Unwrapping the User Keybag: The Class Key Hierarchy

The central on-disk structure for Data Protection is the Keybag:

A binary property list stored in system-managed locations (paths vary with OS releases and boot volume layout).
Contains wrapped class keys and metadata.
Is always consumed by the SEP; the kernel never sees cleartext class keys.

Hierarchy

Hardware UID (UID key):
A device-unique AES key, fused into the Secure Enclave and never exposed outside it.
User password / passcode:
The logical secret known to the user and entered at login or unlock time.
Passcode-derived key (PDK):
The SEP mixes:
- A KDF over the password plus salt (PBKDF2-like).
- The UID key.
- Policy-dependent inputs (e.g. SKP measurement).
  Conceptually:
```
PDK = Tangle( UID, PBKDF2(password, salt), measurement, policy )
```
The exact KDF and tangling function are implementation details, but the key property is: PDK cannot be derived off-device.
Class Keys:
The keybag stores wrapped class keys corresponding to the Data Protection classes:
- Class A (“Complete Protection”):
  Data only accessible while the device is unlocked. Keys are evicted from SEP memory when the device locks.
- Class B (“Protected Unless Open”):
  Similar to Class A, but open file handles may retain ephemeral context to allow certain operations to complete in the background.
- Class C (“Protected Until First User Authentication” / “First Unlock”):
  Keys are brought into SEP memory after the first successful unlock and persist (subject to policy) until reboot. FileVault’s VEK is conceptually associated with this class on Apple Silicon Macs.
- Class D (“No User Secret” / “UID-only”):
  Keys wrapped solely by the UID (and SKP where applicable). Used for data that must be accessible before user login (e.g. some system daemons and metadata). On Apple Silicon, user data is generally not assigned to Class D.

Unwrapping ceremony

When a user logs in on a FileVault-enabled Apple Silicon Mac:

loginwindow submits the password through the authentication pipeline; upon acceptance, the kernel passes:
- The user’s keybag blob.
- The supplied password (or a derivative).
  to the SEP via AppleSEPKeyStore.
Inside SEP:
- The password is run through the configured KDF.
- The UID key and measurement inputs are combined via the tangling function to derive the PDK.
- The keybag’s wrapped class keys are unwrapped using the PDK and UID.
The unwrapped class keys remain resident only inside SEP-protected memory.
The SEP returns handles (numeric identifiers or similar) for the class keys to the kernel rather than the keys themselves.

Subsequent file I/O and volume operations refer to class keys by these handles, never by raw key bits.

10.3.2 Sealed Key Protection (SKP): Binding Data to Measurement

Tahoe introduces and extends Sealed Key Protection (SKP) as a defense against “Evil Maid” scenarios where an attacker boots a compromised or downgraded OS to attack the disk encryption keys.

Measurement chain

During boot:

The Secure Enclave’s Boot Monitor verifies and measures sepOS.
sepOS in turn measures:
- The macOS kernelcache.
- The LocalPolicy describing boot and security configuration (e.g. SIP, boot policy, secure boot level).
These measurements are accumulated into internal registers within the SEP (conceptually similar to TPM PCRs, but not exposed as such).

Sealed keys

When the Volume Encryption Key (VEK) and class keys are created (e.g. at install or FileVault enablement time), they are wrapped under a key derived from:

The UID key.
The passcode-derived material (PDK).
The current boot-chain measurement.

Conceptually:

KEK = KDF( UID, PDK, Measurement )
WrappedVEK = Encrypt( VEK, KEK )

At unlock time:

The same derivation is repeated inside the SEP using the current Measurement.
If the OS, LocalPolicy, or relevant firmware has changed in a way that alters the Measurement beyond allowed ranges, the derived KEK will be different and the unwrap will fail—even if the correct password is supplied.

Security consequence

To successfully decrypt the data volume, an attacker must:

Possess the user’s secret (or otherwise satisfy SEP policy).
Boot into an OS configuration that produces an acceptable Measurement (signed, authorized kernel + LocalPolicy consistent with SKP policy).
Run on the original or equivalently provisioned hardware (UID key, SEP state).

Downgrades to vulnerable kernels, custom kernels, or off-device keybag attacks are blocked at the SKP layer.

10.3.3 The Hardware AES Engine & the Wrapped-Key Path

A common misconception is that the macOS kernel decrypts file contents. On Apple Silicon, the encryption/decryption of user data is handled by a dedicated AES engine on the SoC, integrated with the memory and storage controllers.

Inline encryption path

When a user process performs a file read:

Metadata lookup:
The APFS driver consults file metadata to obtain:
- The identifier or handle for the per-file key (wrapped).
- The relevant class key handle for this file.
Key request to SEP:
The kernel sends:
- The wrapped per-file key.
- The class key handle.
  to the SEP via AppleSEPKeyStore.
SEP translation:
The SEP:
- Unwraps the per-file key using the class key resident in SEP memory.
- Either:
  - Programs the SoC’s AES engine with the resulting key via an internal, non-CPU-addressable interface; or
  - Re-wraps the per-file key under an ephemeral engine-only key and passes that to the AES engine.
DMA from storage:
The kernel issues a read from the NAND-backed storage through the ANS/AGS storage controller, referencing the relevant blocks.
On-the-fly decryption:
As data flows through the storage path into DRAM:
- The AES engine decrypts the ciphertext using the key material that was just programmed.
- The decrypted plaintext is written into the page cache.
Key lifetime:
The AES engine’s key state is ephemeral and tightly scoped to the I/O operation. The AP never sees the cleartext per-file key; the SEP holds the root class keys and controls when engine keys exist.

RE Implication

Forensics and offensive implications:

Dumping kernel memory will reveal plaintext file contents (resident in the page cache) but not the keys that decrypted them.
Per-file and class keys exist only inside the SEP and (transiently) in engine-private state.
Recovering those keys requires either:
- Compromising the SEP firmware and dumping its internal state (e.g., SRAM, xART).
- Attacking the AES engine at the hardware level.

10.3.4 RE Focus: Analyzing the `AppleSEPKeyStore` Kernel Extension

The primary interface between the kernel and the SEP’s key-management logic is the AppleSEPKeyStore kernel extension. For Tahoe and Apple Silicon, this binary is the focal point for understanding the proprietary AP ↔ SEP protocol.

Key responsibilities (RE-derived)

Typical symbols and responsibilities observed across releases include:

aks_unwrap_key / related functions:
- Accept wrapped keys (e.g. from keybags, per-file metadata).
- Prepare and send unwrap requests to the SEP.
- Return handles or status to callers in the kernel.
aks_get_lock_state / equivalents:
- Query the SEP for the current lock / unlock state and biometric backoff state.
- Update kernel-side views of whether user data should be considered accessible.
Message demultiplexers (e.g. sep_key_store_client_handle_message):
- Parse TLV-encoded responses from the SEP.
- Dispatch them to the correct waiters in the kernel or userland.

Attack surface

From a reverse-engineering and exploitation perspective, several patterns emerge:

Handle confusion:
Keys are referred to by relatively small integer handles in the kernel. Bugs that cause handles to be mis-associated across security domains (system vs. user, different users, different contexts) could allow an attacker to induce the SEP to use a more privileged key than intended.
State desynchronization:
AppleSEPKeyStore maintains shadow state about lock status, key availability, and pending operations. Any discrepancy between this state and the SEP’s internal view could create TOCTOU-style conditions where:
- The kernel believes an operation is permitted, but the SEP does not (and vice versa).
- A key handle is assumed valid when the SEP has already invalidated it.
TLV parsing:
The AP-side parser for SEP messages handles complex TLV structures. Memory-safety bugs or logic errors here represent a classic attack surface, albeit one increasingly hardened by modern CFI, PAC, and mitigation layers.

Tahoe hardening (observed)

On Tahoe-era builds, interactions between AppleSEPKeyStore and higher-privilege operations (e.g., enabling FileVault, changing recovery keys, altering LocalPolicy-bound state) show evidence of:

Additional checks that correlate key operations with TXM / GL1 policy decisions.
Stricter coupling between “is this operation permitted under the current Measurement and LocalPolicy?” and “should this unwrap / key creation be forwarded to the SEP?”

Public documentation does not yet spell out this coupling, but runtime traces and binary analysis strongly suggest that Apple is moving more of the authorization logic below the kernel and into the measured, SEP-adjacent policy domain.

11.0 Conclusion: The Attack Surface Landscape

The architectural transformation introduced with macOS Tahoe and the M3/M4 silicon generation signifies the end of the "Kernel is King" era. We have moved from a monolithic trust model, where uid=0 and tfp0 were the ultimate objectives, to a federated security model where the kernel is merely a highly privileged, yet strictly supervised, tenant within a hardware-enforced hypervisor.

For the vulnerability researcher, this necessitates a shift in methodology. Fuzzing syscalls is no longer sufficient to compromise the system's root of trust. The new frontier lies in the Boundary Crossings—the specific, hardware-mediated bridges that allow data and execution flow to traverse the isolated domains.

11.1 Summary of Boundary Crossings

The following matrix details the architectural boundaries, the mechanisms used to traverse them, and the specific attack surface exposed at each junction.

11.1.1 Userland (EL0) ↔ Kernel (EL2/VHE)

The Traditional Boundary, Hardened by Silicon.

Transition Mechanism:
- Entry: SVC (Supervisor Call) instruction triggering a synchronous exception to the kernel exception vector (VBAR_EL1 + 0x400, or the EL2 alias under VHE on macOS).
- Exit: ERET (Exception Return) restoring PC and PSTATE from ELR_EL1/ELR_EL2 and SPSR_EL1/SPSR_EL2 (depending on the concrete VHE configuration).
Hardware Enforcement:
- PAC: Entry points are signed. The kernel verifies the thread state signature (kauth_thread_state) on return, ensuring return-address and register integrity.
- PPL/SPTM: The kernel cannot modify its own text or page tables to disable SMEP/SMAP equivalents (PAN/PXN). Page-table integrity and code immutability are ultimately enforced by the SPTM rather than by EL2 alone.
The Tahoe Shift:
- The kernel is no longer the final arbiter of virtual memory. When a user process requests mmap(RWX), the kernel cannot simply write to the translation tables; it must request the SPTM to map the page.
- Attack Surface:
  - Logic Bugs: Standard memory corruption (UAF, heap overflow) in kernel extensions still yields privileged kernel execution in the EL2/VHE context.
  - PAC Bypasses: Forging pointers to survive the ERET path or function-pointer authentication (return addresses, vtables, dispatch tables).
  - Argument Sanitization: The kernel must sanitize user pointers and lengths before passing them to the SPTM. A "Confused Deputy" attack where the kernel is tricked into asking the SPTM to map a privileged page into user space is the new tfp0.

11.1.2 Kernel (EL2) ↔ Secure Page Table Monitor (GL2)

The "Mechanism" Boundary: The New Hypervisor.

Transition Mechanism:
- Entry: GENTER (Opcode 0x00201420) with the sptm_dispatch_target_t in x16 (encoding Domain + Dispatch Table ID + Endpoint). The 5-bit immediate in the GENTER instruction selects the GXF entry stub and is recorded in ESR_GLx.
- Exit: GEXIT (Opcode 0x00201400), returning from GL2 to the kernel’s EL2/VHE context.
Hardware Enforcement:
- GXF: Hardware context switch of SP_EL2/SP_EL1 → SP_GL2 and the corresponding GL2 state (SPSR_GL2, ELR_GL2, ESR_GL2).
- SPRR: Atomic switch of permission views. Kernel text becomes RO/NX from the GL2 perspective; SPTM text/data become RX/RW as configured for GL2 and remain inaccessible from EL2.
Data Exchange:
- Registers: x0–x7 carry arguments (physical page numbers, ASIDs, permission bitmasks, context IDs). x16 carries the dispatch target (sptm_domain_t + table + endpoint).
- Shared Memory: None in the normal call path. The SPTM reads and writes physical memory directly via its own linear map and page-table view.
Attack Surface:
- State Machine Confusion: The SPTM enforces a Finite State Machine (FSM) on every physical page (Frame Table). The primary attack vector is finding a sequence of retype/map/unmap calls that desynchronizes the SPTM’s view of a page from the hardware’s actual usage (e.g., aliasing a PAGE_TABLE frame as XNU_DATA).
- Input Validation: Passing invalid physical addresses, truncated ranges, or edge-case permission combinations to sptm_map/sptm_unmap/sptm_map_iommu, especially under high contention or refcounted/shared-frame scenarios.
- Panic-as-Oracle: Because invalid or inconsistent requests cause the SPTM to return fatal errors that XNU treats as unrecoverable and converts into kernel panics, timing side-channels or fault-injection during the GENTER window are potential vectors to infer GL2 layout and state (e.g., distinguishing “valid but denied” vs “structurally impossible” transitions via differing panic paths or latencies).

11.1.3 Kernel (EL2) ↔ Trusted Execution Monitor (TXM)

The “Policy” Boundary: Code-Signing and Entitlement Authority.

Transition Mechanism:
- Entry: XNU invokes TXM through txm_kernel_call() and related wrappers. These routines set up a dedicated TXM stack, marshal a call descriptor (selector, argument vector, return buffer), and then perform the CPU sequence required to enter the TXM context. On current iOS releases, reverse-engineering shows that TXM itself uses SVC to perform in-monitor calls; regarding the XNU-to-TXM interface on Tahoe, initial implementations (e.g., iOS 17) utilized raw GENTER stubs, while the explicit txm_* kernel APIs were introduced in later iterations (iOS 18) to wrap these calls.
- Exit: TXM writes its result into the call descriptor, updates a status field, and returns to XNU, which interprets the status. Depending on selector and flags, some TXM failures are converted into kernel panics.
Hardware Enforcement:
- SPTM-Supervised Domain: TXM resides in a region whose code and data are owned and typed by SPTM. XNU has no direct write access to TXM text or critical data; changes must go through SPTM retyping and mapping operations.
- Privilege Ordering: Apple’s OS integrity documentation describes TXM as a lower-privilege component used by SPTM to enforce code-signing and integrity policy. Even if TXM were compromised, SPTM still mediates page-table updates and frame typing; memory integrity does not collapse automatically.
Data Exchange:
- Pointers and Metadata: XNU passes pointers (or physical addresses) to Code Directories, CMS blobs, trust caches, and entitlement structures, along with lengths and flags. TXM interprets these structures and returns accept/deny decisions plus auxiliary metadata.
- Dynamic Trust Cache Operations: TXM selectors cover registration and removal of trust-cache entries, enabling or disabling specific code-signing relaxations, and managing development/debug modes.
Attack Surface:
- Parser Complexity: TXM must parse Mach-O headers, CodeDirectories, CMS/ASN.1, entitlements, and various policy structures. Bugs in these parsers can yield powerful policy-manipulation primitives (for example, arbitrary trust-cache entries or coerced acceptance of malformed signatures), but SPTM still constrains what memory mappings are possible.
- Policy Downgrade and LocalPolicy Handling: Incorrect handling of boot arguments and LocalPolicy data can cause persistent relaxation of code-signing or integrity checks. Exploits here influence what code TXM authorizes, but do not directly grant the ability to arbitrarily rewrite protected frames without also influencing SPTM.
- TOCTOU and Retyping: If the buffers that TXM inspects are not retyped or otherwise shielded by SPTM, there is a window where DMA or kernel code could mutate them between TXM’s checks and subsequent use. Correct integration of SPTM retyping with TXM’s parsing determines how exploitable such races are.

11.1.4 Kernel (EL1) ↔ Secure Enclave (SEP)

The "Air Gap" Boundary: The Parallel Computer.

Transition Mechanism:
- Asynchronous IPC: Mailbox Registers (Doorbell) + Shared Memory Buffers (DART-mapped).
Hardware Enforcement:
- Physical Isolation: Distinct CPU core, distinct MMU.
- Memory Protection Engine: SEP memory is encrypted/authenticated inline.
Data Exchange:
- Serialized Messages: L4 IPC format (Endpoints, TLV payloads).
- Wrapped Keys: Keys are passed as opaque blobs; raw key material never crosses this boundary.
Attack Surface:
- Message Parsing: Fuzzing the sepOS endpoint handlers (e.g., biometrickitd, securekeyvault).
- Shared Memory Races: Modifying the contents of a DART-mapped buffer after the SEP has validated the header but before it processes the payload.
- Anti-Replay Logic: Attempting to rollback the xART storage state to force the SEP to reuse old nonces or counters.

11.1.5 Kernel (EL1) ↔ Exclaves (Secure Domain)

The "Microkernel" Boundary: The RingGate.

Transition Mechanism:
- RingGate: XNUProxy kext marshals data → GENTER (to Secure Kernel) → IPC to Conclave.
Hardware Enforcement:
- SPTM: Enforces physical memory isolation between XNU_DOMAIN and SK_DOMAIN.
Data Exchange:
- Tightbeam: A strongly-typed IDL serialization format.
Attack Surface:
- Proxy Confusion: Exploiting XNUProxy to route messages to the wrong Conclave.
- IDL Deserialization: Bugs in the Tightbeam generated code within the Exclave.
- Resource Exhaustion: Flooding the Secure Kernel with Downcalls to starve secure workloads (DoS).

11.2 The "Intel Gap": Security Disparities between x86 and Apple Silicon

While macOS Tahoe presents a unified user experience across architectures, the underlying security reality is a tale of two operating systems. On Apple Silicon, macOS is a hypervisor-managed, hardware-attested fortress. On Intel (x86_64), it remains a traditional monolithic kernel relying on legacy protection mechanisms. This divergence has created a massive "Intel Gap"—a disparity in exploit mitigation so severe that the same vulnerability often yields a trivial root shell on Intel while resulting in a harmless panic on Apple Silicon.

For the reverse engineer, understanding this gap is essential for targeting. The Intel architecture represents the "Soft Target," lacking the silicon-enforced boundaries of the SPTM, TXM, and PAC.

11.2.1 Lateral Privilege: GL2 vs Ring 0

The critical difference between Intel and Apple-silicon Tahoe systems is the existence, on Apple silicon, of a privilege layer above the kernel that continues to enforce memory-integrity invariants even after a kernel compromise.

Apple Silicon:
- XNU runs at EL2 under the supervision of SPTM in GL2. SPTM is the sole authority for page-table retyping and for managing frame types that correspond to kernel text, page tables, IOMMU tables, and other critical regions.
- TXM executes in a lower-privilege domain than SPTM and provides code-signing and integrity policy decisions. SPTM calls into TXM to decide whether particular mappings or code images are acceptable, but SPTM remains the arbiter of what is actually mapped and how frames are typed.
- A kernel exploit that yields KRW in XNU provides strong influence over control flow and data within EL2 and allows attempts to mis-use SPTM/TXM as confused deputies. However, the attacker must still either:
  - Drive SPTM through an illegal but accepted state transition (retyping or mapping), or
  - Gain sufficient influence over TXM and then exploit the TXM–SPTM interface,
    to obtain equivalent authority over page tables and sealed code.
Intel x86_64:
- The kernel runs in Ring 0 and directly controls page tables, VT-d configuration, and most integrity mechanisms below the T2’s secure boot checks.
- There is no SPTM-equivalent hypervisor above Ring 0 enforcing frame typing or page-table integrity at runtime. Once KRW is obtained and static KTRR is bypassed or worked around, the attacker can patch kernel text, alter page tables, and reconfigure DMA mappings with no higher-privilege arbiter.

Under this model, KRW on Apple silicon is an intermediate privilege level situated below SPTM/TXM, whereas KRW on Intel is much closer to the maximum privilege available to macOS.

11.2.2 Static vs. Dynamic Kernel Integrity (KTRR vs. SPTM)

Both architectures attempt to enforce Kernel Text Read-Only Region (KTRR), but the implementation differs fundamentally in flexibility and robustness.

Intel (Hardware KTRR): On recent Intel Macs, KTRR is implemented via proprietary memory controller registers (configured via MSR).
- Mechanism: The firmware locks a physical range of memory as Read-Only/Executable.
- Limitation: This is Static. Once the range is locked at boot, it cannot change. This forces the kernel to fit all immutable code into a contiguous block. It cannot protect dynamically loaded drivers (KEXTs) with the same hardware rigor. KEXTs rely on software-managed page tables (CR0.WP bit), which a compromised kernel can disable.
Apple Silicon (SPTM):
- Mechanism: The SPTM manages the Frame Table.
- Advantage: This is Dynamic. The kernel can load a new extension (AKC), link it, and then ask the SPTM to "Seal" it. The SPTM transitions those specific pages to XNU_TEXT. This allows the "Immutable Kernel" coverage to extend to late-loaded drivers, a feat impossible on the static Intel KTRR implementation.

11.2.3 The CFI Chasm: PAC vs. CET

Control Flow Integrity (CFI) is the primary defense against ROP/JOP.

Apple Silicon: Pointer Authentication (PAC) is ubiquitous. It protects return addresses (stack), function pointers (heap/data), and C++ vtables. It provides cryptographic diversity based on pointer context.
Intel x86: Intel Macs support Control-flow Enforcement Technology (CET), specifically Shadow Stacks (IBT support is limited).
- The Gap: CET Shadow Stacks protect return addresses effectively, but they do not protect Forward-Edge transfers (function pointers) with the same granularity as PAC.
- Data Pointers: Crucially, Intel has no equivalent to APDAKey (Data Key). An attacker on Intel can still perform Data-Oriented Programming (DOP)—swapping valid object pointers or corrupting decision-making flags—without triggering a hardware fault. On Apple Silicon, these pointers are signed; forging them requires a signing gadget.

11.2.4 The Root of Trust: T2 vs. On-Die Boot ROM

The boot chain trust anchor differs physically.

Intel: The Root of Trust is the Apple T2 Security Chip (on models 2018-2020).
- The Weakness: The T2 is a discrete bridge. It verifies the boot.efi and kernelcache signature before the Intel CPU starts. However, once the Intel CPU is executing, the T2 is effectively a peripheral connected via USB/PCIe. It cannot introspect the Intel CPU's execution state. It cannot stop a runtime kernel exploit.
Apple Silicon: The Root of Trust is the AP Boot ROM.
- The Strength: The security logic (SEP, PKA, Boot Monitor) is on the same die. The Secure Enclave can monitor the power and clock lines of the AP. The SPTM (running on the AP) enforces the boot measurements continuously. The trust chain is not "handed off"; it is maintained throughout the runtime lifecycle.

11.2.5 I/O Security: VT-d vs. DART

DMA attacks are a classic method to bypass CPU memory protections.

Intel: Uses VT-d (Intel Virtualization Technology for Directed I/O).
- Configuration: The kernel configures the IOMMU tables.
- Vulnerability: If the kernel is compromised, it can reconfigure VT-d to allow a malicious Thunderbolt device to overwrite kernel memory (unless strict "DMA Protection" is enabled and locked, which relies on the kernel's integrity).
Apple Silicon: Uses DART (Device Address Resolution Table).
- Enforcement: As detailed in Section 7.2.2, the kernel cannot write to DART registers. Only the SPTM can map I/O memory.
- Result: Even a compromised kernel cannot weaponize a peripheral to perform a DMA attack against the monitor or the kernel text, because the SPTM will reject the mapping request.

11.2.6 Summary Table: Tahoe on Intel vs Apple Silicon

Feature	Intel Mac (x86_64 + T2)	Apple Silicon (arm64e, Tahoe)
Highest effective privilege	Ring 0 kernel with static KIP/KTRR; no higher-privilege macOS component supervising runtime mappings	GL2 SPTM as top-level memory arbiter supervising EL2 XNU; TXM runs below SPTM and supplies code-signing and integrity policy that SPTM consumes for protected mappings
Page-table protection	Memory-controller KIP + software-managed page tables; VT-d tables configured by the kernel	SPRR + SPTM-mediated retyping and mapping for page tables and DART; kernel cannot directly repoint protected frames
Kernel code integrity	Static KTRR region for core kernel text; many KEXTs rely on page-table flags that the kernel can modify	Dynamic sealing of XNU text and AKCs via SPTM/KIP; additional code cannot be introduced as `XNU_TEXT` after boot without passing SPTM’s frame-typing rules
CFI primitive	CET (Shadow Stack + IBT) available in hardware; extent of macOS use is not publicly documented	PAC on kernel and userland code, including return addresses and many vtables
Vtable / data-pointer protection	No hardware authentication for data pointers or vtables	PAC on vtables and selected data pointers (DA/GA keys) constrains many forward-edge and DOP-style attacks
Code-signing enforcement	AMFI / CoreTrust in the kernel enforce policy; T2 participates in secure boot but does not supervise runtime kernel mappings	TXM, running in a domain protected by SPTM, evaluates signatures and integrity policy. On iOS-class platforms, TXM/SPTM together enforce “only signed and trusted code executes”. On macOS, TXM/SPTM primarily protect page-tables and protected code regions while still allowing arbitrary user code execution in accordance with macOS policy.
DMA configuration	VT-d configured and updated by the kernel	DART configured via SPTM dispatch; IOMMU tables live behind SPTM’s frame-typing and mapping rules
Secure enclave / secure coprocessor	Discrete T2 SoC linked over internal buses; cannot introspect x86_64 execution after hand-off	SEP on-die with AP; Exclaves and other secure domains use the same silicon fabric and SPTM/TXM-supervised interfaces
Typical kernel-exploit consequence	KRW + KTRR bypass ⇒ direct and persistent kernel modification and DMA reconfiguration	KRW in XNU ⇒ strong EL2 foothold; additional steps against SPTM/TXM/Exclaves are required to influence sealed code or protected page tables, especially for persistence or for changing hardware-enforced invariants

Conclusion for the Researcher:
The "Intel Gap" means that legacy Intel Macs are essentially running a different, far more vulnerable operating system, despite sharing the macOS version number. Exploits that require complex, multi-stage chains on M3 (e.g., bypassing PAC, confusing SPTM, racing TXM) can often be reduced to a single Use-After-Free and a ROP chain on Intel. As Apple phases out Intel support, the "easy mode" of macOS exploitation is rapidly vanishing.

11.3 Future Trends: The expansion of Exclaves and the death of Kernel Extensions

The trajectory of macOS security architecture is not asymptotic; it is directional. Apple is not merely patching vulnerabilities in XNU; they are actively architecting its obsolescence as a security boundary. The "Tahoe" architecture provides the silicon primitives (SPTM, TXM, GL2) required to execute a long-term strategy of Architectural Attrition.

The future of macOS exploitation lies in understanding two concurrent trends: the ossification of the XNU kernel into a static, immutable appliance, and the migration of high-value logic into the opaque, hardware-isolated world of Exclaves.

11.3.1 The Deprecation of `kmod_load`: The Static Kernel

For decades, the ability to load Kernel Extensions (KEXTs) was a defining feature of macOS. It was also its Achilles' heel. KEXTs run at EL1, share the kernel's address space, and historically lacked the rigorous code review applied to the core kernel.

The mechanism for this—the kmod_load syscall (and the associated kmod_control traps)—represents a massive attack surface. It requires the kernel to possess a runtime linker (kld), capable of resolving symbols, applying relocations, and modifying executable memory.

The DriverKit End-Game:
Apple has systematically introduced userland replacements for kernel drivers: USBDriverKit, HIDDriverKit, AudioDriverKit, and NetworkingDriverKit.

Current State: In Tahoe, third-party KEXTs are deprecated. The userland tool kmutil manages the policy, but the actual loading still relies on the kernel's ability to link code. Loading a legacy KEXT now requires reducing system security (disabling SIP/Secure Boot) and interacting with the TXM via LocalPolicy to explicitly authorize the hash.

Future State: The Death of the Runtime Linker:
We are approaching a point where the kernel will effectively lose the ability to load dynamic code entirely in "Full Security" mode. The goal is to remove the kmod_load logic from the kernel entirely.

The "Sealed" Kernel: The Boot Kernel Collection (BKC) (loaded by iBoot) and the Auxiliary Kernel Collection (AKC) (loaded early by kernelmanagerd) will be the only permitted executable kernel code.
Pre-Linked Immutability: By moving all linking to build-time (kernelcache generation) or boot-time (iBoot verification), Apple can strip the dynamic linker logic (kld) from the runtime kernel. If the kernel doesn't know how to link a Mach-O, it cannot load a rootkit.
SPTM Enforcement: The SPTM already enforces that XNU_TEXT is immutable. The logical next step is for the SPTM to reject any sptm_retype request that attempts to create new XNU_TEXT pages after the initial boot sealing phase is complete.

RE Implication:
The era of the "Rootkit" is ending. If you cannot introduce new code into EL1 via kmod_load, and you cannot modify existing code due to KTRR/SPTM, persistence in the kernel becomes impossible. Attackers will be forced to live entirely within data-only attacks (DOP) or move their persistence to userland (which is easier to detect) or firmware (which is harder to achieve).

11.3.2 Exclave Expansion: Eating the Monolith

If XNU is the "Insecure World," Exclaves are the "Secure World." Currently, Exclaves are used for high-sensitivity, low-complexity tasks (Privacy Indicators, Passkeys). However, the architecture is designed to scale. Apple is effectively strangling the monolithic kernel by slowly migrating critical subsystems out of EL1 and into Exclaves.

Candidates for Migration:

The Network Stack (skywalk):
Apple has already introduced skywalk, a userland networking subsystem. The logical evolution is to move the TCP/IP stack and packet filtering logic into an Exclave.
- Benefit: A remote code execution vulnerability in the Wi-Fi firmware or the TCP stack would compromise an isolated Exclave, not the entire kernel. The SPTM would prevent the compromised network stack from touching system memory.
Filesystem Encryption (APFS):
Currently, AppleSEPKeyStore handles key wrapping, but the bulk encryption happens via the AES Engine managed by the kernel. Moving the filesystem driver's cryptographic logic to an Exclave would ensure that even a kernel compromise cannot exfiltrate file keys, as the keys would exist only within the Exclave's memory domain.
Audio and Media Processing:
To protect DRM content and prevent microphone eavesdropping, the entire CoreAudio engine could be moved to a "Media Conclave."

The "Dark Matter" OS:
As more logic moves to Exclaves, a significant portion of the OS execution flow becomes invisible to standard introspection tools.

No DTrace: You cannot DTrace an Exclave.
No kdebug: Kernel tracing will show a "black hole" where the request enters XNUProxy and vanishes until the result returns.
Opaque State: The memory of an Exclave is physically unmappable by the kernel. A kernel memory dump (coredump) will contain gaps where the Exclave memory resides.

11.3.3 The "Hollow Kernel" Hypothesis

Extrapolating these trends leads to the Hollow Kernel Hypothesis.

In this future architecture, XNU (EL1) is demoted to a Compatibility Shim. Its primary role is to:

Provide POSIX system call semantics for legacy userland applications.
Manage coarse-grained scheduling of CPU resources.
Act as a message bus (via XNUProxy) between userland applications and the real system logic running in Exclaves.

The Security Inversion:
In the traditional model, the Kernel protects the User. In the Hollow Kernel model, the Hardware (SPTM/TXM) protects the System from the Kernel.

The kernel is treated as untrusted code.
The TCB (Trusted Computing Base) shrinks from "The entire Kernel" to "The SPTM, TXM, and specific Exclaves."
A kernel compromise becomes a "Local DoS" or "Privacy Violation" rather than a "System Compromise."

11.3.4 The Visibility Gap: The End of Passive Analysis

For the reverse engineer, this shift is catastrophic for visibility.

Tightbeam IDL: The interface between XNU and Exclaves is defined by Tightbeam. Unlike MIG, which was relatively static, Tightbeam protocols can evolve rapidly. Reverse engineering the system will require constantly reconstructing these serialization formats.
The "Intel Gap" Closure: As Apple phases out Intel support completely, they will likely remove the legacy code paths in XNU that supported the "un-isolated" model. This will make the kernel source code (if still released) increasingly divergent from the binary reality running on M-series chips.
Hardware-Locked Debugging: Debugging an Exclave likely requires "Red" (Development) fused silicon. Researchers working on retail "Green" (Production) hardware will be effectively locked out of analyzing the internal logic of these secure subsystems, forced to treat them as black boxes and fuzz their inputs via XNUProxy.

Final Thought:
macOS is no longer just a Unix system. It is a distributed system running on a single die, governed by a hypervisor that doesn't exist in software. The kernel is dead; long live the Monitor.

1.0 The Silicon Root of Trust: Pre-Boot & Hardware Primitives

1.1 The Reset Vector & Boot ROM (SecureROM)

1.1.1 Execution at Reset: Analyzing the Reset Vector (RVBAR_ELx)

1.1.2 The GID Key (Group ID): Hardware-entangled Decryption

1.1.3 The Public Key Accelerator (PKA): Hardware-Enforced Verification

1.1.4 RE Focus: Dev vs. Prod Fused Silicon

1.2 Proprietary ISA Extensions (arm64e+)

1.2.1 Pointer Authentication (PAC): The Cryptographic Control Flow

1.2.2 Branch Target Identification (BTI): The Landing Pads

1.2.3 New in Tahoe: The Guarded Execution Feature (GXF)

1.2.4 New in Tahoe: Shadow Permission Remapping Registers (SPRR)

2.0 The Secure Enclave Processor (SEP): The Parallel Computer

2.1 SEP Initialization & Boot

2.1.1 The SEPROM: SRAM Execution and the Memory Protection Engine (MPE)

2.1.2 The Boot Monitor: Hardware Enforcement of OS-Bound Keys

2.1.3 Anti-Replay Mechanisms: The Integrity Tree

2.2 SEP Runtime Architecture

2.2.1 The Mailbox Interface: Analyzing the IPC Transport

2.2.2 The Secure Storage Component (xART): Encrypted Persistent Storage

2.2.3 RE Focus: Reverse Engineering the sepOS L4 Syscall Table

3.0 The Chain of Trust: Firmware & Bootloaders

3.1 Low-Level Bootloader (LLB)

3.1.1 Parsing the Image4 (img4) Container

3.1.2 DRAM Training and Memory Controller Configuration

3.1.3 Verifying the Exclusive Chip ID (ECID) and Board ID

3.2 iBoot (Stage 2 Bootloader)

3.2.1 The Apple Device Tree (ADT)

3.2.2 New in Tahoe: Loading the Security Monitors

3.2.3 LocalPolicy & BAA: The Shift to Local Signing

3.2.4 RE Focus: Decrypting iBoot Payloads via the AES MMIO Interface

4.0 The Security Monitor Layer (GL1/GL2): The Exclave Architecture

4.1 The Secure Page Table Monitor (SPTM) - GL2

4.1.1 The GENTER and GEXIT Instructions: Context Switching

4.1.2 The Frame Table (FTE): Tracking Physical Reality

4.1.3 The Dispatch Table: Reverse Engineering the Selectors

4.1.4 RE Focus: Analyzing Panic Strings and the State Machine

4.2 The Trusted Execution Monitor (TXM) – GL0

4.2.1 Decoupling AMFI: Moving Core Code-Signature Verification

4.2.2 The Trust Cache: Static vs. Loadable

4.2.3 Developer Mode Enforcement and Downgrade Protection

5.0 XNU Kernel Initialization: Entering GL1

5.1 The start routine and KASLR

5.1.1 Deriving the Kernel Slide: The Decoupled Address Space

5.1.2 Initializing the MMU: TCR_EL2 and the SPTM Handshake

5.2 Hardware Security Enforcements (The "Kill Switch" Registers)

5.2.1 KTRR (Kernel Text Read-Only Region): The Physical Lock

5.2.2 Kernel Integrity Protection (KIP) and SPTM Sealing

5.2.3 The System Control Register (SCTLR_EL2) Lockdown

5.3 Exclaves: The Microkernel within the Monolith

5.3.1 The L4 Influence: Domains, Conclaves, and IPC

5.3.2 RE Focus: The RingGate Mechanism and XNUProxy

5.3.3 Use Case: Secure Control of Privacy Indicators and Passkeys

6.0 The Mach Subsystem: The Nervous System

6.1 Mach Ports & IPC Primitives

6.1.1 Port Rights: Receive, Send, Send-Once, and Dead Names

6.1.2 The IPC Space (ipc_space) and the Global Name Server

6.1.3 Copy-on-Write (CoW) optimizations in Out-of-Line (OOL) message passing

6.2 The host_priv Port

6.2.1 The “God Mode” Handle: Generation and Restriction

6.2.2 Task Special Ports: The Privileged Directory

6.2.3 RE Focus: Fuzzing Mach Message Parsing (MIG)

7.0 IOKit & Driver Architecture

7.1 IOKit Initialization

7.1.1 The IORegistry: Populating the Device Tree into C++ Objects

7.1.2 Boot, System, and Auxiliary Kernel Collections

7.1.3 RE Focus: PAC-signing of C++ Vtables (OSObject) and BLRAA

7.2 DriverKit (dexts)

7.2.1 Moving drivers to userland: IOUserClient and Entitlement Checks

7.2.2 Memory Mapping Constraints and IOMMU (DART) Protection

7.3 The Graphics Stack (AGX)

7.3.1 RTKit: The Proprietary RTOS running on the GPU Coprocessor (ASC)

7.3.2 IOMobileFramebuffer (IOMFB): Secure Framebuffers and Exclave Compositing

7.3.3 DART: The IOMMU Wall and DMA Containment

8.0 Userland Bootstrap: The Birth of PID 1

8.1 launchd: The Mach Port Broker

8.1.1 Transition from Kernel to Userland: The First execve

8.1.2 Initializing the Bootstrap Port (Subset of the Name Service)

8.1.3 Parsing launchd.plist and the Binary Protocol for XPC Service Lookups

8.2 The Dynamic Linker (dyld)

8.2.1 Mapping the Dyld Shared Cache (DSC)

1.1.1 Execution at Reset: Analyzing the Reset Vector (`RVBAR_ELx`)

2.2.3 RE Focus: Reverse Engineering the `sepOS` L4 Syscall Table

3.1.1 Parsing the Image4 (`img4`) Container

4.1.1 The `GENTER` and `GEXIT` Instructions: Context Switching

5.1 The `start` routine and KASLR

5.1.2 Initializing the MMU: `TCR_EL2` and the SPTM Handshake

5.2.3 The System Control Register (`SCTLR_EL2`) Lockdown

5.3.2 RE Focus: The `RingGate` Mechanism and `XNUProxy`

6.1.2 The IPC Space (`ipc_space`) and the Global Name Server

6.2 The `host_priv` Port

7.1.3 RE Focus: PAC-signing of C++ Vtables (`OSObject`) and `BLRAA`

7.2.1 Moving drivers to userland: `IOUserClient` and Entitlement Checks

7.3.2 `IOMobileFramebuffer` (IOMFB): Secure Framebuffers and Exclave Compositing

8.1 `launchd`: The Mach Port Broker

8.1.1 Transition from Kernel to Userland: The First `execve`

8.1.3 Parsing `launchd.plist` and the Binary Protocol for XPC Service Lookups

8.2 The Dynamic Linker (`dyld`)

8.2.2 RE Focus: Code Signature Validation (`fcntl(F_ADDFILESIGS)`) and the Call to TXM

8.2.3 ASLR in Userland: Chained Fixups and the Death of `dyld_info`

8.3.1 The “Split OS” Architecture: `/System/Cryptexes/OS`

9.1 `amfid` (Apple Mobile File Integrity Daemon)

9.1.1 The Interaction between `launchd`, the Kernel (MACF), and `amfid`

9.1.3 Exception Handling: How `get-task-allow` and Debugging Entitlements are Processed

9.2 `sandboxd` & The Seatbelt Policy

9.3 `tccd` (Transparency, Consent, and Control)

10.1 `loginwindow` & `opendirectoryd`

10.1.2 `loginwindow`: The Shield Window and Session State

10.1.3 `opendirectoryd`: The Authentication Broker

10.2.1 The Daemon Hierarchy: `coreauthd` → `biometrickitd` → SEP

10.3.4 RE Focus: Analyzing the `AppleSEPKeyStore` Kernel Extension

11.3.1 The Deprecation of `kmod_load`: The Static Kernel