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 changed 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 that 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 its boot security policy, 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 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. Among other things, that means that the version of macOS installed on it must be the same as (or more recent than) that installed on the internal SSD. This isn’t clearly explained in Apple’s Platform Security Guide, where the three levels of security are explained 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 practice, at least as far as Big Sur 11.3.1 is concerned, Full Security means that the system allows only booting macOS which has the same (or a later) version as that installed on the internal disk. Once its internal SSD has been updated to 11.3.1, an M1 Mac won’t boot from 11.3 or earlier on any external disk in Full Security mode (with one notable exception described below).

Yesterday, I explained how you can change this by dropping the boot policy for an external disk to Reduced Security. That lets you boot an external disk which you want to update to the current release of macOS, or to boot from a historical release of macOS for test purposes. To understand the how and why you need to look at what happens when an M1 Mac boots macOS, something the Platform Security Guide is very good at explaining, but doesn’t even mention how it works with external bootable systems.

The boot process

This diagram is a first 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. If this imposes Full Security, the version of macOS on that boot volume group is compared against that on the internal SSD, which is stored in /SFR/current/SystemVersion.plist in iSCPreboot. 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 macOS versions match, boot proceeds normally. If the macOS version of the external disk is older than that in SystemVersion.plist, the boot process is halted and Startup Manager is loaded, giving the user a graceful exit. If LocalPolicy is for Reduced or Permissive Security, then boot proceeds regardless of macOS versions, allowing the Mac to start up in an older version of macOS.

At present, the odd situation is when LocalPolicy is set to Full Security and the macOS versions don’t match, but the external disk is connected via USB-A rather than USB-C or Thunderbolt. In that circumstance, it appears that booting continues despite the conflict in macOS versions. This could be a simple bug, but I suspect that it’s a limitation of the USB-A bus (I recall historical issues in which USB-A had problems with security systems which could be related).

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.

Anticipating problems which would arise if this LocalPolicy were for Full Security and the local version of macOS conflicted with that running on the internal SSD, Startup Manager and the Startup Disk pane will refuse to restart when such a conflict exists. Unfortunately the error message which is displayed isn’t helpful to the user, as it doesn’t explain how they can address this problem, merely offering to help them install a fresh current version of macOS, which normally isn’t what the user wants.

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. However, they don’t appear to be of much use to those with M1 Macs, as all attempts to install an older version of macOS on an external disk appear to fail.

This is so consistent that it’s unlikely to be unintentional: I believe that full installer apps are designed only to run successfully in versions of macOS older than the version which they will install. Thus, the 11.3 full installer will work when run in 11.2.3 or earlier, but not in 11.3.1. This appears to reinforce the Full Security policy, which denies access to versions of macOS with known vulnerabilities.

Platform Security Guide

This invaluable document should be available here. However, the current (February 2021) version is only available in US English. As Apple’s support website will automatically redirect you to a localised copy, and those still don’t appear to have been updated to the current edition, to read about the M1 you’ll need to view this PDF version instead.