The macOS Boot Process: From Firmware to the Login Window

The transition to Apple Silicon changed macOS’s boot process more fundamentally than any macOS release before it — not just a new CPU architecture, but a boot chain modeled directly on iOS’s, with a dedicated Secure Enclave verifying every stage before handing off to the next. Understanding both the old Intel path and the current Apple Silicon path explains a lot about why the two platforms behave differently around security, recovery, and startup customization.

Intel Macs: EFI and boot.efi

Intel-based Macs follow a path much closer to a standard UEFI PC: Apple’s EFI firmware initializes hardware, then loads boot.efi from the EFI System Partition, which in turn loads the kernel (kernelcache on modern versions) and hands off control.

# From a running Intel Mac
nvram -p | grep boot-args

boot-args, stored in NVRAM, is the closest Intel-Mac equivalent to a kernel command line — used historically for things like verbose boot (-v) or disabling specific kernel protections during development and debugging.

Apple Silicon: a chain rooted in hardware

Apple Silicon Macs boot through a chain modeled on the iPhone’s: the Boot ROM, burned into the chip at manufacture time and immutable, is the very first code that runs, and it verifies the cryptographic signature of the next stage (LLB, the Low-Level Bootloader) before executing it. LLB in turn verifies and loads iBoot, which verifies and loads the kernel — each link in the chain checking the signature of the next before handing off, all the way from silicon-burned trust anchor to a running kernel.

# From a running Apple Silicon Mac
bputil -d          # display the current boot policy

This is a genuine secure boot chain, not just a checksum — each stage’s signature is verified against keys ultimately rooted in the Secure Enclave, and a tampered LLB, iBoot, or kernel image fails verification before it’s ever executed, rather than being caught after the fact.

Boot security policies

Apple Silicon Macs let you choose a security policy per installed macOS volume group, from Full Security (only Apple-notarized OS builds the Secure Enclave currently trusts may boot) down through Reduced Security (allows older signed OS versions and unsigned kernel extensions), configured from Recovery Mode’s Startup Security Utility:

# From Recovery Mode
bputil -m -u <user> -p            # switch to a less restrictive security policy, interactively

This is also why running a kernel extension (rather than a modern system extension) or booting an older macOS version on Apple Silicon requires deliberately stepping down from Full Security first — the secure boot chain won’t permit it under the default, strictest policy.

Recovery: a second, minimal OS

Both platforms boot into a separate Recovery OS for reinstallation, disk repair, and (on Apple Silicon) security policy changes — held either on a local Recovery volume or fetched over the internet (Internet Recovery) when the local copy itself needs repair.

# Reboot into Recovery on Apple Silicon: hold the power button at startup
# On Intel: hold Cmd+R during boot

Kernel and kernel extension loading

Once the kernel itself is running, it loads its built-in kernel extensions and, if permitted by SIP and the boot security policy, any signed third-party kernel extensions — increasingly superseded by system extensions, which run in userspace with a much smaller blast radius, reflecting Apple’s ongoing push to get third-party code entirely out of kernel space.

kextstat | grep -v com.apple
systemextensionsctl list

loginwindow: the handoff to a usable session

Once the kernel and core system daemons (launchd’s earliest jobs) are running, loginwindow starts and presents the login UI — itself just another launchd-managed process, though one with special responsibility for authenticating a user and starting their actual session.

Why the Apple Silicon model is stricter by design

The practical upshot of Apple Silicon’s chained verification is that tampering with any single stage — firmware, bootloader, or kernel — is detected before that stage ever runs, not after the fact by scanning a running system. That’s a meaningfully stronger guarantee than Intel Macs’ EFI-based boot offered, at the cost of deliberately making certain low-level customizations (custom kernel extensions, alternate OS installs) require an explicit, documented step down in security policy rather than being available by default — a trade-off consistent with the same philosophy behind SIP and notarization: security defaults that assume most users should never need to loosen them.

How the verification chain is actually implemented: measurement, not just checking

Each stage in the Apple Silicon boot chain doesn’t just verify the next stage’s signature and move on — it also measures it, extending a running cryptographic hash that accumulates evidence of exactly what code has executed so far in this specific boot. This measured-boot approach is what makes features like FileVault’s integration with the boot chain meaningfully secure: a disk encryption key release can be conditioned on the accumulated measurement matching an expected, known-good chain, meaning even a technically correctly-signed but unexpected component substituted somewhere in the chain changes the measurement and can be detected, not just an outright signature failure. This is a stronger property than simple pass/fail signature verification alone, since it creates an auditable, cumulative record of the specific boot path taken rather than only independent yes/no checks at each individual stage.

DFU mode: recovery below even the Boot ROM’s normal operation

For a Mac Apple Silicon that’s damaged badly enough that even the Boot ROM’s own recovery paths (Recovery OS, Internet Recovery) can’t help — a botched low-level firmware update, for instance — DFU (Device Firmware Update) mode provides a still-lower-level recovery path, requiring a second Mac and Apple Configurator 2 connected via USB-C to “revive” or fully restore the device’s firmware from outside the machine’s own boot chain entirely. DFU mode exists specifically because every other recovery mechanism described above still depends on at least the Boot ROM and some minimal amount of working firmware being present and functional — DFU is the fallback for when even that baseline can’t be assumed, treating the stuck Mac as a target to be reflashed externally rather than a system capable of participating in its own recovery.

Why boot-args matters less than it used to on Apple Silicon

Intel Macs’ boot-args NVRAM variable was a genuinely powerful, broadly trusted mechanism for altering kernel behavior at boot — disabling specific security checks, enabling verbose diagnostics, changing low-level kernel parameters. On Apple Silicon, many of the most security-sensitive boot-args values are only honored at all once the boot security policy has been explicitly lowered from Full Security via bputil, precisely because honoring them unconditionally under the default strictest policy would undermine the entire point of the measured, chained verification covered above — a boot argument capable of disabling a security check is, from the chain’s perspective, functionally similar to tampering with a boot stage directly, and is gated by the same policy mechanism as a result.

Related:

Sources: