Boot ROM Security on Silicon Macs (M1/M2/M3)

Booting is the process of starting a computer by loading the operating system into memory. It’s called that as a shorthand for “bootstrapping,” referring to the system metaphorically pulling itself up by its own bootstraps to become fully operational. It has multiple steps to progressively verify and load components, while maintaining the computer’s security. Apple Silicon (M1/M2/M3) introduced a new macOS boot architecture resembling that of iPhones and iPads. The entire boot process follows a chain of trust, where each stage cryptographically verifies the next.

Today, I am starting a 4-part series. It will explore the boot stages on Apple Silicon Macs, and the security designs within them. When possible, I will cover how to see these boot stages on your Mac! Best of all, I document the history of boot exploits in each stage. If I missed an important exploit, please let me know.

Boot ROM (SecureROM) stage

When a Silicon Mac powers on, the on-chip Boot ROM (also called SecureROM) executes first. A Boot ROM is a read-only memory chip that stores the initial code a device runs at startup to initialize hardware and load the operating system or firmware.

If you want to see the specific identifier for your hardware’s boot code without digging through menus, you can use the Terminal: system_profiler SPHardwareDataType | grep "Firmware". It will spit out the version currently running.

The Boot ROM code is built into the system-on-a-chip (SoC) hardware, and cannot be altered by software updates. Its primary job is to initialize the processor and verify and load the next-stage boot loader.

The Boot ROM contains Apple’s root of trust (public key material) used to validate the signature of the next component (aka, the Low-Level Bootloader, which will be my next post). If this verification fails (e.g., due to corruption or an unauthorized component), the Boot ROM will not proceed to normal boot. Instead, it reverts to recovery mode.

Device Firmware Update (DFU)

On Silicon, the fallback is DFU mode. The system will wait for a host computer to connect over USB and restore a valid image.

This design ensures that unsigned or tampered boot code cannot run. Either the chain of trust continues successfully, or the device enters recovery/DFU mode for repair.

Diagram by Dr. Howard Oakley

How can I see the SecureROM stage on my mac? The best I’ve found on the Mac today is: an easier method to put a MacBook into DFU mode by Kevin M. Cox

SecureROM security

Boot process for a Mac with Apple silicon (source).

The Boot ROM is stored in read-only memory on the SoC, preventing malware from modifying it.

Its code is minimal and purpose-built, reducing potential attack surface. It includes only basic hardware support (e.g., just enough USB for DFU, basic flash storage access) to minimize vulnerabilities.

The Boot ROM holds Apple root certificates or public keys used to check that the next-stage bootloader is genuinely Apple-signed.

A root certificate is a trusted cryptographic credential embedded in the Boot ROM that verifies the authenticity of Apple’s digital signatures during the boot process.

On iOS and Silicon, this often involves a personalized signature tied to the device’s unique ID for the highest security. On Macs configured for “Full Security” (the default), the Boot ROM and subsequent loaders will only accept an Apple-trusted bootloader that is also the latest authorized version for that device, preventing rollback to older, possibly vulnerable, boot code. Thus, from the first instruction, Silicon Macs enforce Secure Boot via cryptographic signature checks.

Boot ROM attacks

Because the Boot ROM is read-only and executed before any user control, vulnerabilities here are rare but mega powerful if found. A Boot ROM exploit enables code execution at the earliest stage, potentially bypassing all subsequent signature checks.

Historically, iOS devices had these exploits. For example, Checkm8 (2019) was an exploit targeting the Boot ROM (“SecureROM”) of iPhones up to the A11 chip. Checkm8 could not be patched on existing hardware, and it enabled permanent jailbreaks on those devices.

The same vulnerability was found to affect the Apple T2 security chip, which is essentially an A10 in older Intel Macs. In 2020, researchers demonstrated that the T2’s Boot ROM was vulnerable to Checkm8, allowing untrusted code execution in the T2 at boot. This meant an attacker with physical access could put a T2-equipped Mac in DFU mode, use the exploit to gain code execution in the T2’s secure boot process, and thereby bypass its security functions (e.g., disabling firmware password, altering Secure Boot settings, or installing a keylogger in the T2 which manages keyboard input).

Apple could not patch this on existing T2 chips because the flaw was in ROM. Fortunately, code running via this exploit was not persistent; it had to be redone after each reboot, since the Boot ROM itself can’t be modified.

To my knowledge,

no Boot ROM exploits have been publicly disclosed for M-series chips. The Boot ROM in these newer chips appears to have avoided the mistakes present in earlier designs. Nonetheless, any flaw in the Boot ROM would be “game over,” as it could permanently undermine the chain of trust.

Past iPhone exploits (like the 2010 “limera1n” on A4, or Checkm8 on A5-A11) illustrate the risk. If I had this type of exploit, I could execute arbitrary code early in the boot process, potentially subverting all higher-layer defenses.

Here, Apple’s approach has been to keep the Boot ROM as simple and formally verified as possible, and to address any discovered flaws by revising the hardware in the next chip generation. For example, after Checkm8, Apple ensured all A12-and-later chips (and thus all M1/M2/M3) were not vulnerable to that specific bug. The lack of UEFI firmware on Silicon (unlike Intel Macs) also eliminates an entire class of firmware attacks. The Boot ROM implements secure boot directly, without a legacy BIOS/EFI, so I could not hook into option ROMs or UEFI drivers as I could on older systems.

Evolution

Because a Boot ROM bug cannot be patched post-manufacture, I think Apple’s strategy is prevention. In practice, this means auditing and limiting the Boot ROM’s capabilities.

Silicon’s Boot ROM doesn’t support booting from arbitrary external media in the Boot ROM itself.

Again, this is unlike Intel Macs, which would run option ROMs or UEFI from USB.

Someone on Hacker News noted that iBoot (the later stage bootloader) “doesn’t support USB host mode to boot from USB disks, because the attack surface there is massive.” I agree with this assessment.

Silicon achieves external boot by delegating more of it to higher-level code with user authorization, rather than in the immutable ROM. This design decision was probably intended to reduce potential vulnerabilities in the early boot processes.

TLDR: Defenses at the Boot ROM stage include locked-down hardware, cryptographic verification of the next stage, minimal features, and a secure fallback (DFU) if anything is amiss. Everything here makes it extremely hard for an attacker to ever execute unauthorized code at this fundamental level.

After the Boot ROM authenticates and launches it, the Low-Level Bootloader (LLB) runs. This will be the subject of my next article!

Also, if you enjoyed this post, consider reading EDR Evasion with Lesser-Known Languages & macOS APIs.

Sources, thanks, and where to learn more

A special thanks to Dr. Howard Oakley for all of his documentation on this process. I have never met him, but he is one of the primary inspirations and reasons (his blogs and tools) I can accessibly research Macs. Many of the sections in this post cite his work as the starting point.