Apple silicon Macs are the first Apple computers to feature fully secure boot processes as one of their fundamental design goals. Although similar in some ways to those in Apple’s devices and in Intel Macs with T2 chips, there are substantial differences. Unlike T2 Macs, secure Boot in Apple silicon is maintained even when starting up from external storage, a feature completely unsupported by devices. Non-standard configurations are also available to give greater flexibility with reduced security modes, which are absent from devices. This article explains how to manage Secure Boot on Apple silicon Macs.

Full Security

By default, Apple silicon Macs start up in Full Security, the mode recommended by Apple for normal use. That requires:

• Following pre-boot stages, a Signed System Volume (SSV) is loaded from its snapshot, with its seal intact and signature verified.
• The only kernel extensions loaded during boot are those supplied by Apple in macOS. No third-party kernel extensions can be loaded.
• System Integrity Protection (SIP) is fully enabled.

Because they run outside the privileged space of the kernel and its extensions, third-party system extensions and their relatives can be loaded and used fully.

Booting in Full Security applies full control and verification of all components from the Boot ROM, through the Low-Level Bootloader (LLB) and iBoot ‘firmware’, to the kernel and its extensions in the SSV. If any part of that sequence fails to verify, the boot process is halted and, depending on where the failure has occured, the Mac is either put into DFU or Recovery mode for the user to address the problem. This not only ensures robust security throughout, but it also guards against potential conflicts such as those arising with third-party kernel extensions, and unintentional corruption of any component.

Changing security

Control over boot security is applied using Startup Security Utility when booted in paired Recovery (except in Big Sur, as explained below). Access this by starting the Mac up into normal paired Recovery with a single long hold of the Power button. When the first screen has loaded, click the Options button, then from the Utilities menu select the Startup Security Utility command.

You will then be prompted to select the boot volume group whose security policy will be set. Note that in macOS 12.0.1 and later this must be the same as that for the paired Recovery being used.

By default that will already be in Full Security. Set the new policy as explained below, and click the OK button. To apply that policy, select the Restart command to exit Recovery and start up in normal user mode.

Startup Security Utility changes the LocalPolicy settings for that boot volume group; those are stored in the iSCPreboot volume on the hidden Apple_APFS_ISC container on the internal SSD of that Mac. Full details of LocalPolicy are given in Apple’s Platform Security Guide, and explained here.

Big Sur is a notable exception to the requirement to change security settings in the paired Recovery volume: it doesn’t have a paired Recovery volume, but boots into Recovery from a hidden container on its internal SSD, from where Startup Security Utility controls security settings for all mounted boot volume groups.

Fallback Recovery (frOS) is unable to change LocalPolicy, thus Startup Security Utility is unavailable when booted in frOS, its most distinctive feature.

Although the bputil command tool gives access to security settings, its use to modify them is hazardous, and shouldn’t be attempted unless you know what you’re doing and are prepared to have to restore that Mac in DFU mode. It is, though, sometimes useful as an aid to solving problems with LocalPolicy settings, as explained here.

Reduced Security

When reducing security settings, the only other option available is Reduced Security, which forms the gateway to Permissive Security as well. There are two other common reasons for selecting Reduced Security, though: to enable the loading of third-party kernel extensions, and to run older versions of macOS.

To enable the loading of third-party kernel extensions, Reduced Security must be set, and the upper checkbox ticked. Once this has been applied by a restart, installation and loading of the kernel extension can proceed using its installer and Privacy & Security settings. That doesn’t enable loading of the kext on demand, as in the past, as it has to be merged into a signed Auxiliary Kernel Collection, from where it can loaded during startup.

Although Apple states that Reduced Security is required to run older versions of macOS, that doesn’t appear to be required at present. Reduced Security differs from Full Security in that LLB and iBoot trust ‘global’ signatures that are bundled with macOS rather than using personalised signatures for iBoot and beyond. For many, this may appear to be an insignificant reduction compared with Full Security, although it does add the risks of loading third-party kexts when used for that purpose.

Permissive Security

Startup Security Utility doesn’t offer Permissive Security as an option until Reduced Security has been selected and an action has been taken to downgrade that to Permissive Security. The most likely reason for doing this is to partially or completely disable SIP using csrutil, and once that has been performed this third setting is shown in Startup Security Utility.

Just as with Reduced Security, this offers two further options in checkboxes, including that to enable the loading of third-party kernel extensions.

The main reason for using Permissive Security is to reduce SIP settings, and I have recently provided a guide to the controls available in csrutil. The normal sequence for changing those is to start up in paired Recovery, open Startup Security Utility, set that to Reduced Security and click on the OK button. Following that, open Terminal, run the appropriate csrutil command, then restart the Mac, which will automatically be in Permissive Security.

The security effects of Permissive Security are determined largely by changes made to SIP and other controls. Although signatures are still validated throughout the chain of boot stages, ‘global’ signatures are trusted for iBoot and beyond, as are boot objects signed locally by the Secure Enclave. At its most extensive, this allows the use of a fully untrusted kernel, such as a debug or custom version. The penalty is that some decryption keys are no longer available, and those restrict features available in macOS, such as Apple Pay, which is normally disabled.

Reversing Permissive Security requires fully enabling SIP using csrutil, undoing any other relevant security settings, then using Startup Security Utility to set a higher level of security. In some cases, that may entail installing a fresh macOS with its SSV. Apple also notes that, on Apple silicon Macs, SIP settings aren’t stored in NVRAM but in the LocalPolicy.

External Boot Volumes

With the notable exception of Big Sur, boot security settings are saved into the LocalPolicy for the boot volume group containing that paired Recovery system, although all LocalPolicy settings are saved to the internal SSD, never to an external disk. This relies on the concept of ownership, as explained here. This can bring its own problems, as explored here.

Summary

• Unless there’s a good reason, leave boot volume groups in Apple silicon Macs in Full Security.
• If your Mac needs to load a third-party kernel extension, run it in Reduced Security with those kernel extensions enabled.
• Partially or completely disabling SIP requires Permissive Security, which brings significant penalties, and may require more extensive work to undo.
• Use Startup Security Utility rather than bputil.

Reference

Apple’s Platform Security Guide