Boot ROM and Secure Boot on Apple Silicon: from power-on to iBoot

The macOS boot article walked the chain from iBoot to launchd. This article fills in what happens before iBoot — the silicon-level boot of Apple Silicon, the Boot ROM that anchors trust, the LLB and iBoot signature checks, and how the SEP boots alongside.

Power-on: the SoC starts in a known state

The moment power flows to the SoC, the chip is in a controlled reset state. Most of the silicon is held in reset; one specific core — typically a single E-core — begins executing from a hardcoded address that points into the Boot ROM.

Boot ROM is literal ROM: silicon mask-programmed at manufacture, immutable, unpatchable. It contains a small program (a few KB) whose job is to bootstrap the rest of the boot chain.

What Boot ROM does, in roughly this order:

1. Configure the bare-minimum hardware needed to read flash: memory controller, the storage interface, basic clock.
2. Load LLB (Low-Level Bootloader) from the SoC's NOR flash into RAM.
3. Verify LLB's cryptographic signature against an Apple public key whose hash is fused into the SEP at silicon manufacture.
4. If signature valid: jump to LLB.
5. If signature invalid: enter a recovery state — DFU mode, accessible via USB-C from a connected Mac.

The Boot ROM key is the cryptographic anchor of the entire system. Everything else chains to it.

LLB — the Low-Level Bootloader

LLB is the second-stage bootloader. Its job:

1. Initialize more hardware — full memory training (DDR calibration), more clocks, PMU bring-up.
2. Decide which bootloader to load next based on boot policy:
   • Normal boot: load iBoot (the main bootloader).
   • DFU mode: load the DFU-mode firmware that exposes a USB-C interface.
   • One True recoveryOS: load the rOS-specific iBoot variant.
3. Verify the chosen next-stage signature against Apple's chain.
4. Jump.

LLB is signed by Apple. The Boot ROM verified LLB at step 3 above; LLB now verifies iBoot the same way before handing off.

iBoot — and the SEP boots alongside

iBoot is the main bootloader (see the iBoot glossary entry). By the time it runs, the main CPU is fully initialized; iBoot's job is to load the kernelcache.

But crucially, the SEP boots in parallel with all this:

• The SEP has its own Boot ROM that runs from a separate hardcoded address.
• The SEP's Boot ROM loads sepfw (SEPOS), verifies its signature against keys baked into the SEP.
• SEPOS comes up, services start, the SEP signals readiness via the mailbox.

iBoot waits for the SEP-ready signal before continuing — the rest of boot needs the SEP available for things like FileVault unlock.

See the Secure Enclave article for what SEPOS does once it's up.

The kernelcache load

iBoot does the heavy work of preparing for kernel boot:

1. Read the boot policy from nvram + the Preboot volume. This tells iBoot which kernelcache to use (normal, recovery, internal), and what security mode to honor.
2. Load the kernelcache from the Preboot volume.
3. Verify the kernelcache signature against the boot policy. If Reduced Security is enabled and a user-approved kext is included, the kernelcache may have been re-signed locally — iBoot checks this against the policy's locally-trusted keys.
4. Construct the Device Tree — a binary blob describing what hardware is present on this SoC variant, what addresses each peripheral lives at, what interrupts they use. The kernel will read this to know its environment.
5. Set up the initial address space for the kernel (page table base, exception vector address).
6. Jump to the kernel's entry point (_start in osfmk/arm64/start.s).

From here, the boot article takes over.

What "secure boot" actually guarantees

Apple's secure boot guarantees:

1. The Boot ROM code is what Apple shipped (mask-programmed, immutable).
2. Every subsequent stage's code is signed by Apple and verified before execution.
3. Modifications to any stage's code break the signature and the device refuses to boot that stage.
4. The system can be downgraded only to versions Apple's secure-boot policy still allows (anti-downgrade is encoded in the policy).

What it does not guarantee:

• That the running kernel hasn't been exploited at runtime. Secure boot is about load-time trust; runtime exploitation is a separate concern (see SIP, SSV, AMFI).
• That physical attacks on the SoC can't extract keys. Apple's defenses here are physical (mesh, voltage detectors) but not absolute.

Boot modes — different paths through the same chain

The same secure boot machinery handles several boot modes:

• Normal boot: standard kernelcache.
• recoveryOS boot: hold the power button on Apple Silicon to enter the boot menu, choose recovery; iBoot loads the recovery kernelcache.
• One True recoveryOS: a small recovery image that lives outside any user-replaceable volume; the ultimate fallback.
• DFU mode: iBoot fails to start; Boot ROM exposes a USB-C endpoint that lets a connected Mac restore the device.
• Internal-only modes: reachable via internal Apple tools; not user-facing.

All of these go through Boot ROM and LLB — the gate-keeping doesn't go away just because you booted into recovery. Recovery's iBoot variant is still Apple-signed.

Anti-downgrade

Apple's secure-boot policy includes a counter that increments with security-relevant updates. A device that's been updated to OS version N won't accept a kernelcache for version N-1 if the security counter is older — the policy refuses.

This is what prevents an attacker from "downgrading" a device to an older OS with known kernel exploits to then attack the user. Once Apple ships a fix, devices that pick up the fix can't be rolled back below it.

What surprises newcomers

• The Boot ROM is the only mutable-by-Apple thing here. Once a Mac is in your hands, the Boot ROM is immutable — even Apple can't update it.
• The SEP boots independently. It's effectively a parallel boot chain.
• DFU mode lives in Boot ROM. If everything else is broken, Boot ROM's USB stack still works — that's the always-available rescue path.
• Anti-downgrade is part of secure boot. Older OS versions aren't loadable once the security counter has advanced.

What to read next

For Apple's authoritative documentation on the boot chain, see Apple's Platform Security Guide — Secure boot.

For the open-source side that takes over once Boot ROM hands off:

And the macOS boot article for everything after iBoot's kernelcache load.