Your MacBook boots through a chain of trust: each stage is cryptographically signed, and each stage verifies the next before handing over control. Compromise any link and the chain breaks — the Mac refuses to boot.
When you press the power button, the Power Management IC (PMU) sequences the power rails in a specific order — VCORE, VDDR, IO — to prevent damage from voltage spikes. Once stable, the Apple Silicon SoC's CPU cores come out of reset at a hardcoded address in the SecureROM.
SecureROM is mask-programmed ROM — written once during chip fabrication. It is physically impossible to modify without destroying the chip. Apple bakes roughly 32KB of code into the silicon at the factory. No firmware update, no exploit, no DFU mode can change it. This is the unconditional trust anchor.
SecureROM reads iBoot from NAND flash and verifies its ECDSA/RSA signature against Apple's Root CA certificate. The certificate is also stored in ROM. Any bit flip in iBoot's code changes the signature hash — verification fails.
If iBoot is corrupted or modified, SecureROM enters Device Firmware Update (DFU) mode. The Mac appears dead but is actually waiting for a USB-C connection to a Mac running Apple Configurator or Finder's Recovery mode. This is how you restore a brick.
If all checks pass, SecureROM jumps to iBoot's entry point. From this moment, SecureROM's job is done — it doesn't run again until the next power cycle.
The Secure Enclave (SEP) is a separate processor on the Apple Silicon die. It has its own ROM, RAM, and runs its own OS (sepOS). It boots independently and holds long-term cryptographic keys — Touch ID templates, Face ID models, your disk encryption key. The main CPU never has direct access to these keys. Even if an attacker fully compromises macOS, Secure Enclave secrets remain protected.
iBoot is Apple's bootloader — software stored in NAND flash that can be updated via firmware updates (but always signed and verified). It bridges the hardware initialization phase and the OS loading phase.
Before any data can be stored in RAM, the memory controller must calibrate timing parameters — signal delays, voltage levels, timing margins — for the specific DRAM modules on this exact logic board. This "memory training" takes ~200–400ms and is the single slowest hardware initialization step.
iBoot configures initial page tables so the CPU can use virtual addresses. This allows later code to run at fixed addresses regardless of physical memory layout. The real page tables will be rebuilt by the XNU kernel.
macOS lives on an APFS Sealed System Volume (SSV). The entire contents are hashed into a Merkle tree. iBoot computes the root hash and compares it against the expected value. Any modification to any system file — a single byte in any dylib — changes the root hash, and the Mac refuses to boot.
The SSV seal is why /System/Library and /usr/bin are mounted read-only. Even root can't write to them without disabling SIP and breaking the seal. On production Macs, this means the entire OS is tamper-evident.
iBoot reads the XNU kernel from the APFS volume into RAM, verifies its signature, builds a device tree (a data structure describing all hardware: CPU cores, memory map, I/O controllers, peripherals), and jumps to the kernel's entry point with the device tree pointer in a register.
| Policy | What's Allowed | Use Case |
|---|---|---|
| Full Security (default) | Only Apple-signed OS matching current macOS | All normal Macs |
| Reduced Security | Older macOS, developer kexts with notarization | Development, older software |
| Permissive Security | Any OS, unsigned code, custom kernels | Security research, Linux on Mac |
XNU is a hybrid kernel: it combines the Mach microkernel, the BSD UNIX subsystem, and the I/O Kit driver framework into a single kernel image. This architecture gives Apple performance (monolithic kernel — everything runs in kernel space) and flexibility (Mach IPC allows modular-like communication).
After the kernel finishes bootstrapping, it executes /sbin/launchd as PID 1. launchd is Apple's universal service manager — it replaced BSD init, inetd (network services), cron, and rc scripts all in one process.
launchd's key innovation: services don't start at boot — they start when first needed. com.apple.mDNSResponder starts when your first DNS-SD query arrives. com.apple.bluetoothd starts when Bluetooth is enabled. This is why macOS boots faster than it appears: fewer services actually run at startup than you think.
| Location | Type | Runs As | Purpose |
|---|---|---|---|
/System/Library/LaunchDaemons/ | Daemon | root | Apple system services |
/Library/LaunchDaemons/ | Daemon | root | Third-party system services |
/System/Library/LaunchAgents/ | Agent | user | Apple per-user agents |
/Library/LaunchAgents/ | Agent | user | Third-party per-user agents |
~/Library/LaunchAgents/ | Agent | user | Your personal agents |
Step through each boot stage, or play the full boot sequence. Watch how early WindowServer starts — the Apple logo appears way before the kernel is done initializing everything!
After login, launchd (PID 1) has spawned hundreds of processes. Click any node to expand its children and see what each process does.
| Stage | Intel Mac (2017–2020) | Apple Silicon (M1+) |
|---|---|---|
| Root of trust | T2 chip (separate from CPU) | SecureROM on the SoC itself |
| Boot ROM | EFI firmware (~16MB, updateable) | SecureROM (~32KB, immutable) |
| Bootloader | UEFI + macOS BootPicker | iBoot (Apple custom) |
| OS seal | SIP + code signing | Sealed System Volume (SSV) |
| Boot time | 20–40s (UEFI POST) | 8–15s (no BIOS POST) |
| DRAM training | SPD-based, fast | Custom, longer (200–400ms) |
~/Library/LaunchAgents (Zoom, Dropbox, etc.)launchctl list | grep -v apple — third-party servicessudo fs_usage -e -f filesys /sbin/launchdlog show --last boot | grep error