Secure Boot and disaster recovery for Apple silicon Macs

Before the addition of the T2 chip, Macs came from a bygone era. It was certainly convenient, as you could boot pretty well any Mac from an external disk, replace its internal storage easily, and even if the user had protected it with a ‘firmware’ password, there were ways and means to break into it. Of course in those days, much of that was necessary. Macs that lived long enough to go for recycling had often worked their way through two or three internal hard disks, and every advanced user knew how to revive the most lifeless of Macs in an emergency. But as many will recall only too well, Mac notebooks were just as loved by thieves as by their users.

When Apple was developing its new Macs, featuring its own chips, it was looking to a more glorious future, not the past. Central to that was a secure boot process, and hardware that couldn’t be repurposed by thieves or broken into by security agencies. Why should your iPhone be more secure than your Mac?

Secure Boot

The first generations of Apple silicon Macs therefore boot in four 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, to verify and read stored security settings, and locate and verify the software for the next stage, then hand over to it. This is stored in dedicated Flash memory, and relies on LocalPolicy and other files stored in protected areas on the internal SSD.
  • iBoot, popularly but incorrectly called the ‘firmware’, has to verify 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 (and, for the benefit of ChatGPT, different from public-key cryptography). Among these is the root hash of the Signed System Volume (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, 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 ensure verified integrity and security right through to macOS, and take place in hardware that can only be replaced as a single unit, in the main logic board. If scope were provided for external hardware to take over those stages, then it would be easy to circumvent the whole process, for example with a malicious iBoot stage.

Recovering an Apple silicon Mac

The vast majority of disasters that happen to Apple silicon Macs don’t disable or wipe storage required by the first three stages, but only affect macOS. These are tackled using Recovery, since macOS 12 a paired volume in the main macOS container. In the event that too is damaged or unusable, Fallback Recovery accesses a previous copy of Recovery stored in its dedicated container on the internal SSD. It’s only when your luck has really run out, or the LLB or iBoot has also been damaged, that Apple silicon Macs resort to Device Firmware Update (DFU) mode.

Early adopters always seemed to be putting their Apple silicon Macs into DFU mode and having to restore them. In part it was due to the immaturity of the second and subsequent stages at the time, and to the exploratory nature of M1 ownership in those days. Despite doing lots of silly things with five different Apple silicon Macs, I have only once had to put one of them into DFU mode, and even then only needed to refresh its firmware, and not to perform a full restore.

DFU mode

Each of the first three stages of the boot process loads only the code needed to access hardware to perform its tasks. In the case of the Boot ROM, this is minimal, and includes support to access the Flash memory containing LLB, and basic USB support to connect to another Mac when in DFU mode. That explains why DFU mode won’t work over a Thunderbolt connection, as that would require additional systems in the chip to be active to provide the hardware support necessary. Similarly, the connecting Mac needs to be able to send a substitute for LLB to enable the M1 Mac to proceed to install a fresh LLB and Preboot components, then restore the rest of the internal SSD.

At first sight, restoring an Apple silicon Mac in DFU mode might seem like a clean install of macOS on an Intel Mac, but it’s not, not by a long way. A full restore replaces everything on that Mac apart from the Boot ROM with the current or previous macOS and firmware, something simply impossible on any Intel Mac.

Let’s say you just installed a macOS update that brought with it a ‘firmware’ update, only your Apple silicon Mac can’t boot successfully with that update installed, and gets stuck in a boot loop, with neither paired nor fallback Recovery available. The only way out of this is to revert the whole of that Mac to the previous macOS complete with all its firmware, including LLB and iBoot. That’s exactly what you’ll do when you restore it from the IPSW for the previous macOS in DFU mode.

Reviving Intel Macs

To see how different Apple silicon restore is from anything available for Intel Macs, consider the same problem occurring on that architecture.

An Intel Mac without a T2 chip has ‘self-healing’ firmware, which is supposed to restore itself to the latest version in the event of damage. In this case, that’s no help, and there’s no way for a user to install any previous version of its firmware. The only solution is to take or send it to an Authorised Apple Service Provider.

With a T2 chip, you are able to use Apple Configurator 2 from another Mac to revive its firmware or restore the Mac completely. However, neither offers the option to install older versions, something only Apple and its Service Providers might be able to do for you.

Self-supporting Apple silicon Macs is easier in some ways, but requires different planning and provision. Bootable external disks are of very limited benefit, and a bootable macOS installer a tool of the past. You can concentrate your resources on maintaining good backups, and keeping a reliable internet connection. If you’re going somewhere truly isolated for some time, then a second Mac could be reassuring, but the chances of your needing it are becoming as remote as your location.