Behind the scenes of iOS and Mac Security

Overview: Ivan Krstić, Head of Apple Security Engineering and Architecture, presents platform security innovations across macOS and iOS. Krstić explains Apple's departure from traditional x86 UEFI Secure Boot architectures in favor of custom silicon co-processors. The presentation details hardware-enforced boot protections against pre-RAM Direct Memory Access (DMA) attacks and untrusted Option ROMs on the Apple T2 chip, alongside advanced hardware security primitives on iOS including Kernel Integrity Protection (KIP), Fast Permission Restrictions (APRR), Page Protection Layer (PPL), and Pointer Authentication (PAC).

Key Topics: - Mac Secure Boot architecture via Apple T2 co-processor and pre-RAM VT-d DMA containment - UEFI Option ROM isolation, Ring 3 demotion, and Option ROM Sandbox Driver mediation - Hardware-enforced iOS Kernel Integrity Protection (KIP v1 and v2) mitigating kernel code execution - Dynamic code signing enforcement via PPL and control-flow integrity using ARMv8.3 PAC

Technical Details: To address vulnerabilities in standard x86 UEFI secure boot implementations, Apple built Mac Secure Boot atop the custom T2 security chip and Secure Enclave. Boot initialization begins within T2 on-chip ROM, verifying each stage before passing execution to the x86 processor. To counter physical Direct Memory Access (DMA) attacks from Thunderbolt and PCIe accessories, Apple evolved Intel VT-d (IOMMU) protections from the kernel into early UEFI firmware. Because PCIe bus 0 devices initialize before system RAM is online, untrusted hardware could overwrite unexecuted firmware. To eliminate this race condition without RAM, Apple pre-compiled an all-zero page table directly into the UEFI firmware binary mapped in processor cache, enabling VT-d before RAM initialization to enforce a default-deny DMA policy against PCIe bus 0.

Apple also tackled PCIe Option ROMs, which traditionally execute in Ring 0 within a shared virtual address space. Apple isolated Option ROMs by demoting them to Ring 3, allocating dedicated virtual memory spaces, and inserting an Option ROM Sandbox Driver. Tested via Intel Simics simulation, this driver reduces available EFI protocols from 1,500 to six, blocking Option ROM attempts to modify NVRAM security configurations or hook Apple Secure Boot protocols.

Turning to iOS, Krstić details Kernel Integrity Protection (KIP). While KIP v0 was an EL3 software monitor vulnerable to race conditions, KIP v1 (iPhone 7) embedded custom hardware into the CPU memory controller to enforce read-only kernel text by overriding page table mappings and eliminating TTBR1 write gadgets. In iPhone XS, KIP v2 hardened these controls into unmodifiable hardware bits preserved across power transitions. For userland, Apple developed the Page Protection Layer (PPL) and Fast Permission Restrictions (APRR). APRR allows instantaneous per-thread memory permission toggling via CPU registers without syscalls or TLB invalidation, enforcing W^X in JavaScriptCore. PPL isolates page table management into a micro-TCB accessible only via verified trampolines, maintaining userland code integrity beneath a compromised kernel. Finally, ARMv8.3 Pointer Authentication (PAC) cryptographically signs pointers using five hardware-backed keys (IA, IB, DA, DB, GA) with address diversification to thwart ROP and control-flow hijacking.

Key Takeaways: Robust platform security requires tightly integrating custom hardware primitives with operating system enforcement rather than relying solely on software controls. Demoting untrusted early-boot drivers like Option ROMs to Ring 3 and pre-configuring IOMMU page tables in processor cache neutralizes physical DMA attack surfaces. On mobile operating systems, isolating translation table management into hardware-guarded layers like PPL and signing pointers with cryptographic PAC instructions ensures attackers with arbitrary kernel read/write primitives cannot execute unsigned code or subvert control flow.

(AI summary — Gemini Flash)