Little more than a fortnight ago, I attempted to detail how M1 Macs running Big Sur version 11.3.1 apply LocalPolicy to determine whether an external disk can be booted. Little did I realise then that this would all change completely when Apple released macOS 11.4. This article attempts to explain this in the light of those major changes.

One of the big differences between a Mac running macOS and a device running iOS/iPadOS is that the Mac can start up from an external disk.

Intel Macs without a T2 chip do this very simply, and provided that the external disk is compatible, has a suitable version of macOS installed, and has been ‘blessed’ as bootable, you can walk up to a Mac, start it up from that disk, and use it. The only thing which could stand in your way is if the user has enabled its firmware password.

The T2 chip changed this completely. Unless the user has already altered its default security settings to allow it to start up from an external disk, you’ll have no joy whatsoever. Although this is secure, it’s also more than inconvenient, as the times you most need your Mac to start up from an external disk are when it’s in trouble with its internal disk, and that’s likely to prevent you from changing its security settings, leaving your Mac dead.

M1 Macs aim to address this shortcoming of T2 models: the ability to start an M1 Mac from an external disk isn’t directly controlled by the boot security policy for its internal disk, and it should be possible to boot an M1 Mac from an external disk without having to change any security settings. As there isn’t any direct control, it might look as if that’s the case, but security policy can still get in the way and prevent you from starting an M1 Mac up from an external disk. This article explains how that happens, among other things.

Boot Security Policy

Unlike a T2 Mac, M1 Macs don’t set one boot security policy for the whole Mac, but a policy for each bootable disk. This is attractive, as it means that you can still ensure that, when it boots from its internal SSD it does so in Full Security, but your M1 Mac can be more relaxed when it boots from an external disk instead. This is implemented in per-disk LocalPolicy files which are stored in the iSCPreboot container of the internal SSD at /[volume-group-uuid]/LocalPolicy/[policy-hash].img4.

When you select an external disk as the boot disk in the Startup Disk pane, it looks for that disk’s LocalPolicy. If it finds none, a new LocalPolicy is created, defaulting to starting up from that disk in Full Security mode. Apple’s Platform Security Guide explains the three levels of security as:

• “Full Security: The system behaves like iOS and iPadOS, and allows only booting software which was known to be the latest that was available at install time.”
• “Reduced Security: […] This allows the system to run older versions of macOS. Because older versions of macOS inevitably have unpatched vulnerabilities, this security mode is described as Reduced. This is also the policy level required to support booting kernel extensions (kexts).”
• “Permissive Security: The system behaves like Reduced Security […], but it also tells iBoot that it should accept some boot objects being signed by the Secure Enclave with the same key used to sign the LocalPolicy. This policy level supports users that are building, signing, and booting their own custom XNU kernels.”

In macOS 11.4, the wording used for Full and Reduced Security can lead to confusion. All releases of Big Sur can now be booted in Full Security, even though those prior to 11.4 are known to have unpatched security vulnerabilities. Whereas in earlier versions of macOS 11, it had been necessary to downgrade some older releases of Big Sur to Reduced Security, for those boot disks to work properly with later releases on the internal SSD, that’s no longer a requirement.

There are two common situations in which macOS requires a boot disk to operate at a lower security level: third-party kernel extensions and changed major security settings including SIP.

For an M1 Mac to be able to load a third-party kernel extension, that boot disk has to have a LocalPolicy of Reduced or Permissive Security. When running at Full Security, those kernel extensions can’t be loaded. Similarly, when you use the csrutil command in Recovery to disable SIP (or make other changes to key macOS security systems), that boot disk will be downgraded to Permissive Security. It’s a requirement of Full Security that all major security systems are active.

The boot process

This diagram is a second draft of how I understand this to work, and is based on the information provided by Apple, that revealed by the Asahi Linux team, and a little of my own work and imagination.

Fairly early during the boot process, the Mac must determine which startup volume group it’s intended to use. As the Low-Level Bootloader (LLB, Stage 1) has to validate LocalPolicy for that startup disk, it appears to be LLB which does that from a setting in the NVRAM. At some stage, either LLB or iBoot (Stage 2) has to check Local Boot Policy, which is stored against the lobo key in the LocalPolicy file in the iSCPreboot container of the internal SSD at /[volume-group-uuid]/LocalPolicy/[policy-hash].img4. In the diagram above I presume that occurs before iBoot is loaded, but that could occur later during the second stage boot.

If LocalPolicy is for Full Security and the Seal and policies are good, boot proceeds normally. If signatures or policies are incompatible with the chosen security level, the boot process is halted and Boot Recovery Assistant is loaded, giving the user a graceful exit. This is also true of LocalPolicy for Reduced or Permissive Security.

Human interface

Users normally control which startup volume group is to be used to boot that Mac in two places: the Startup Manager in Recovery Mode, and the Startup Disk pane in System Preferences. When the user selects one of the available startup disks there and tries to restart that Mac, macOS checks whether a LocalPolicy file exists for that disk. If no LocalPolicy exists, one is created using default settings, otherwise the current file is used.

If macOS detects a problem with starting up from the chosen boot disk, then it normally falls back to recoveryOS and opens the Boot Recovery Assistant, which offers to reinstall macOS or choose another startup disk.

macOS full installers

The final piece in this jigsaw puzzle is the macOS full installer app. In response to user outcry when it removed the macOS 11.2 installer as soon as 11.2.1 was released, Apple now leaves full installers available for each version of Big Sur. Prior to macOS 11.4, old installers frequently failed when run in a more recent release of Big Sur. In 11.4, you should now be able to run and install any released version of macOS 11, provided that Apple hasn’t revoked its signature for that installer. Versions before 11.2 may suffer problems, though, with incompatibilities with more recent firmware.

Platform Security Guide

This invaluable document is available here. Previous versions weren’t available for non-US English, but Apple has now addressed that it should be fully accessible. If you need the PDF version, that’s available from here.