In the first of these two articles looking at how Mac firmware has changed, I summarised what happened before the release of the first Macs with T1 processors in 2016, followed by the T2 in 2017. While the T1 was primarily concerned with system management and Touch ID, and didn’t attempt to secure the boot process, the T2 introduced Secure Boot for Intel Macs and served as a pilot platform for Secure Boot for the Apple Silicon models to come in 2020.

T2 firmware

With two separate processors in each T2 Mac, there are two separate sets of firmware, one EFI and the other known as iBridge or BridgeOS. Following the established pattern, both are only updated by macOS installers and updaters, which are also designed to conceal the iBridge component; while some users open up Apple’s installers to perform isolated EFI firmware updates, that doesn’t appear to be possible for iBridge firmware without using Apple Configurator 2. Installing iBridge firmware invokes a uniquely scary process in which the whole of the Intel system, including processor and display, are shut down, leaving the user with an apparently dead Mac until the T2 has been updated and the rest of the Mac can be brought up again.

Following standard power-on self-test and SMC initialisation, the T2 sub-system establishes the level of Secure Boot in force, and, if that’s Full or Medium Security, boot.efi is checked before being loaded. By default, Macs with T2 chips can’t be started up from external disks, because of this Secure Boot; that can only be changed by entering Recovery mode and changing settings there.

Macs with T2 chips also make full use of the Signed and Sealed System Volume in Big Sur and Monterey. While Intel Macs without T2 chips do still perform a basic check on the System volume, only those with T2 chips or Apple Silicon fully verify the integrity of the boot system using its hash tree.

The T2’s protection is far superior to that in a regular Intel Mac, but it has still been broken on occasion. The most feasible of these techniques uses the Checkm8 exploit, although it appears that one security company has recently claimed to have discovered how to crack passwords secured by the T2. It’s not clear how reliable that technique is.

M1 Macs

The aim of boot security in M1 Macs is to provide a verified chain of trust through each step in the boot process to the loading of macOS, which can’t be exploited by malicious components. Booting an M1 series Mac thus consists of four main stages:

• The Boot ROM, which is in the hardware, and can’t be changed. In this context, its most important task is to verify the executable for the next stage, load and run it. If that isn’t possible, then the fallback is to go into DFU mode and await a connection over USB.
• The Low-Level Bootloader, LLB, which verifies and reads stored security settings in the LocalPolicy, locates and verifies the software for the next stage, then hands over to it.
• iBoot, popularly but incorrectly called the M1 ‘firmware’, which verifies a set of hashes used to guarantee the integrity of key information, by comparing a stored copy of the hash against a hash of that hash, termed its signature. Among these is the root hash of the SSV, but iBoot doesn’t attempt to access the SSV or its hashes, merely passing on the verified root hash for the kernel to use later. Once it has completed those checks according to LocalPolicy, iBoot verifies, loads and runs the macOS kernel.
• macOS, whose kernel takes over from iBoot to start up the rest of the hardware, security systems, the SSV and other storage, and load all the required kernel extensions. These ultimately bring the Mac to life, and the user login screen.

These are summarised in the following diagram.

Two of the most obvious differences from Intel Macs with T2 chips are the ability to boot from external storage without reducing security, and eliminating the need for key combinations to engage different startup modes including Recovery.

Maintaining full security when booting from external storage is a major benefit of the LocalPolicy system introduced with the M1. This in turn relies on the fact that the Secure Enclave is integrated into the chip, rather than external to the main CPU, and can rely on secure storage on the M1’s internal SSD. It’s also more elaborate, and, at least in early versions of Big Sur, wasn’t particularly reliable, but that appears to have been addressed since. The trade-off is that booting an M1 Mac is completely dependent on its internal storage for the early stages of the boot process.

Use of the Power button to trigger ‘1 True Recovery’ has both improved security of Recovery mode and made its features more accessible. Instead of the user having to memorise a list of different key combinations required to access different features, all are now integrated within a single environment. Further improvements to the interface should enhance this in the future.

Recovery has already evolved from its initial version in Big Sur, which only offered the single version of recoveryOS in a dedicated container on internal storage (and its fallback, when available). In Monterey, the same Power button signal triggers booting from a Recovery disk image contained in the Recovery volume associated with the previous boot system. That adds the flexibility to engage the version of Recovery supplied with the most recently active macOS.

Firmware updates

T2 and M1 Macs have also brought significant improvements in the reliability of firmware updates. Early T2 firmware updates showed a tendency in rare cases to render the Mac unbootable when anything went wrong during an update. That has since become even more infrequent, and Apple Configurator 2 now offers better facilities, including the ability to downgrade the firmware in a T2 chip.

M1 Macs are still too young and homogeneous to tell whether their firmware updates are any more reliable. In their case, Configurator can completely wipe and reinstall internal storage, returning that Mac to factory condition with fresh firmware.

Conclusions

In less than five years, Macs have gone from essentially unsecured firmware with little security in the boot process, to a fully secure process which delivers, installs and runs firmware which shouldn’t be exploitable. What started with eficheck and the incorporation of firmware updates in macOS installers has become central to macOS security.