Until relatively recently, security has tended to be an afterthought, something to be added once a computer and its chips have been designed. In the development of Apple silicon chips, not only was security designed in at the start, but Apple implemented and evolved part of it in the T2 chip over the years preceding the first release of Apple silicon Macs. The end result, though, is different in important respects, and overcomes some of the disadvantages of the approach adopted by the T2.

Secure Boot

The goal is for the whole of the boot process to run using code and resources that are verified before they’re loaded. This occurs in five 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 an external 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 referred to as ‘firmware’, which verifies a set of hashes used to guarantee the integrity of key information, by comparing a stored copy against a hash of that hash, its signature. Among these is the signature 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 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.
• cryptexes, cryptographically signed disk image files, which load some macOS components such as Safari that remain outside the SSV so they can be updated without a full macOS update, in particular through a Rapid Security Response (RSR).

In the event that anything goes wrong, such as a verification failure, there are only two likely courses: the Mac is put into DFU mode to await connection from another Mac, or it’s put into Recovery instead. Each of the first three stages loads only the code which it needs 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 Apple silicon Mac to proceed to install a fresh LLB and Preboot components, then restore the rest of the internal SSD.

As with most modern instruction architectures, the CPU cores in Apple silicon chips have hardware support for accelerated computation of the hashes used in the verification performed in each stage of Secure Boot, and in the SSV.

Signed System Volume (SSV)

In macOS Mojave, the system and user data are stored in a single boot volume. In Big Sur and later, they’re divided between two volumes that are joined together at specific locations using special firmlinks, to form the boot volume group, which extends to a paired Recovery volume, and another hidden volume for virtual memory swap files. The internal SSD of an Apple silicon Mac also has two hidden partitions or containers used by the system, that aren’t present on those of Intel Macs.

To ensure the integrity of the System Volume, macOS boots not from that volume itself, but from a snapshot made of it during installation or update. This includes a tree of cryptographic hashes used to verify its integrity. Rather than just save the hash of each file, which would make verification of all those hashes a lengthy process, groups of hashes for files are hashed again, and so on up to a single master hash or seal at the top of a whole tree of hashes. That master hash for all the hashes in the tree is then hashed again to form its signature, hence the Signed System Volume.

At first verification during booting, the signature is verified. As parts of the directory tree are accessed, they can be progressively verified against hashes lower down in the hash tree, as required. This verifies the integrity of the SSV without the long delay that would be required to verify its entire contents in one stage.

One part of the system remains outside the full protection of the SSV and cryptexes: third-party kernel extensions installed on the Data volume. Although these are now brought within a kernel collection, as they remain a vulnerability, for them to be loaded the user has to reduce security in Startup Security Utility, in Recovery mode, and explicitly enable them to be loaded. This is changed behaviour from an Intel Mac with a T2 chip.

External bootable disks

Another shortcoming of Intel Macs with T2 chips is their reliance on booting from their internal SSD to achieve Full Security. If the user wishes to boot a T2 Mac from an external bootable disk, then that has to be explicitly enabled in their Startup Security Utility. Apple silicon Macs normally run at full security when starting up from an external disk as a result of features in Secure Boot.

This is because the early stages of Secure Boot must be run from the internal SSD, before external storage can be mounted and the startup process transferred to its boot volume group, and that transfer must be in accordance with stored LocalPolicy for that external boot volume group. That in turn requires ‘ownership’ of the external boot volume, and a slightly more elaborate installation and configuration.

The end result is both more flexible and secure than booting an Intel Mac with a T2 chip from external storage, can sometimes be a bit more fiddly to set up, but always requires the boot process to start from the internal SSD. For those who get scared by the prospect of its premature failure, that may be a challenging concept, but it brings with it the security of knowing that your Mac can’t be started up by anyone passing by with a bootable external disk in their hand.

Secure Enclave

To support these extensive security features, biometrics in the form of Touch ID, and for the protection of secrets more widely, Apple silicon has a Secure Enclave with its own Secure Enclave Processor (SEP), running its own operating system sepOS. Apple has provided extensive details about this in the M1 chip, but hasn’t updated that for the M2 or M3 yet.

Recovery

There would be little point to Secure Boot if it could be bypassed in Recovery mode, so Apple silicon Macs have a completely different means of entering Recovery to ensure that it can’t be used as a convenient backdoor. Gone are the arcane combinations of keys held down during startup. Instead, the only way to enter Recovery is by the physical press of the Power button, normally a press-and-hold action.

Entering Safe mode requires the same process at first, then the selection of the boot volume group (disk) to be used before initiating a restart into Safe mode. Because of its reliance on the Power button, this is normally performed from a cold start, with the Mac shut down, rather than a restart, which is less convenient.

macOS can in some circumstances restart an Apple silicon Mac in Recovery, but the only way that a user can put their Mac into Recovery is using the Power button, which requires physical contact with the Mac.

Virtual macOS

In addition to CPU cores featuring instructions to accelerate cryptographic services including hashing, they include a mode to support virtualisation of guest operating systems. From those, Apple has implemented lightweight macOS Virtual Machines, which can offer features not readily available.

Those allow a more recent Apple silicon Mac, such as an M3 model, which can’t run macOS Monterey or Ventura natively, to run those older versions, although macOS 11 Big Sur isn’t supported as a guest or host OS. As macOS VMs can use Rosetta 2 translation to run Intel code, when Apple discontinues support for that translation in a future macOS, it will enable users to run Intel-only apps in macOS VMs.

While the performance of macOS VMs is very close to native, they have limitations at present, the most severe of which is their lack of support for Apple ID, hence almost all apps in the App Store.

Concepts

• Security is built into Apple silicon rather than added as an afterthought.
• Secure Boot ensures the complete verification of each step in the boot process.
• The SSV ensures the complete integrity of the System volume.
• Starting up from an external disk doesn’t require any compromise to Secure Boot, nor any change in security settings.
• Security and secrets are protected by a Secure Enclave with its own processor core and operating system.
• Recovery mode can only be entered by pressing the Power button, and can’t be used to bypass security.
• Virtual macOS can give access to older versions that can’t be run natively on more recent Macs.

Previously in this series

Apple silicon: 1 Cores, clusters and performance
Apple silicon: 2 Power and thermal glory
Apple silicon: 3 But does it save energy?
Apple silicon: 4 A little help from friends and co-processors
Apple silicon: 5 Memory and internal storage

Further reading

Booting an M1 Mac from hardware to kexts: 1 Hardware
Booting an M1 Mac from hardware to kexts: 2 LLB and iBoot
Booting an M1 Mac from hardware to kexts: 3 XNU, the kernel
Ventura volume layout
An atlas of recovery and boot volumes: High Sierra to Monterey
Make a Ventura bootable external disk for an Apple silicon Mac
Ownership of Apple silicon Macs matters: how it can stop external bootable disks
An illustrated guide to Recovery on Apple silicon Macs
Startup and Recovery Modes on M1 and M2 Macs
Why are Apple silicon VMs so different?
Summary of macOS VM performance on Apple silicon Macs

Evaluating M3 Pro CPU cores: 1 General performance
Evaluating M3 Pro CPU cores: 2 Power and energy
Evaluating M3 Pro CPU cores: 3 Special CPU modes
Evaluating M3 Pro CPU cores: 4 Vector processing in NEON
Evaluating M3 Pro CPU cores: 5 Quest for the AMX
Evaluating the M3 Pro: Summary
Finding and evaluating AMX co-processors in Apple silicon chips
Comparing Accelerate performance on Apple silicon and Intel cores
M3 CPU cores have become more versatile