Reading view

There are new articles available, click to refresh the page.

How Macs boot securely, or can’t

Earlier this week, I explained how the Signed System Volume (SSV), Data volume and cryptexes are integrated into the boot volume group, to support a secure boot process. This article outlines how modern Macs tackle the problem of booting securely.

The aim of a secure boot process is to ensure that all steps from the Boot ROM to the operating system are verified against any unauthorised change, and the code loaded and run is as intended. A simple operating system might achieve that by running only code contained in a boot ROM, but that’s woefully inadequate for any modern general-purpose operating system such as macOS, which also needs to be updated and upgraded during a Mac’s lifetime. Thus the great bulk of macOS has to be loaded and run from mutable storage, now SSDs. Those and a great deal else require specialised cores, with their own firmware, and features like the Secure Enclave. This is achieved in a cascade, where each step provides access to more of the Mac’s hardware, until many of Sequoia’s 670 kernel extensions are loaded and ready.

Intel Mac without T2 chip

Older models of Macs without a T2 chip follow a classic and insecure process when booting. Their Boot ROM loads UEFI firmware, and that in turn loads boot.efi, the macOS booter, without performing any verification. The macOS booter then loads the prelinked kernel from disk, again without verifying it. When the kernel opens the SSV, any checks on that can only be cursory, as Recovery for these Macs doesn’t offer controls in the form of a Startup Security Utility.

In High Sierra (2017), Apple introduced eficheck to periodically run checks on the version and integrity of UEFI firmware, although that doesn’t take place during the boot process, and was discontinued in macOS 14 Sonoma.

Intel Mac with T2 chip

These are the first Macs to support Secure Boot, thanks to their T2 chip, which is based on a variant of Apple’s A10 chip, dating back to 2016; the first model featuring a T2 chip was released at the end of 2017. As shown in the diagram at the end of this section, these Macs start their boot process with their Boot ROM verifying the iBoot ‘firmware’ for the T2 chip. That in turn verifies the kernel and its extensions for the T2, and that verifies the UEFI for the Intel side of the Mac.

Booting the Intel chipset proceeds similarly to older Intel Macs, but each step verifies the code to be run by the next, until its immutable kernel is loaded and boots the rest of macOS. Early in that stage, the kernel verifies the SSV before proceeding any further. Failure in any of the verifications halts the boot process, if you’re lucky in Recovery or T2 DFU mode.

SecureBoots1

This diagram compares boot processes in the three modern Mac architectures.

Apple silicon Mac

In the absence of any Intel chipset, Apple decided to implement its own Secure Boot, although there are options that could have allowed it to remain with UEFI. M-series chips tackle this in four steps:

  1. Boot ROM, which verifies the Low Level Bootloader (LLB).
  2. LLB, sometimes described as the first stage, concerned with loading and booting some auxiliary cores, security policy, and verifying the second stage, iBoot.
  3. iBoot, which continues validations and verifications, including signatures and root hash of the SSV, before handing over to the kernel.
  4. The kernel, which boots macOS.

Apple silicon chips contain many specialist cores responsible for implementing hardware features such as Thunderbolt. Firmware for each of those has to be verified and loaded to boot those cores, a task performed by LLB and iBoot.

Security policy for each boot volume group is set in its LocalPolicy, and has to be loaded and validated by LLB. The SSV is verified by iBoot prior to handing over to the kernel, to ensure the file system has been checked before it’s mounted.

When running in Full Security, the only kernel extensions to be loaded are those supplied in macOS, forming the standard Boot Kernel Collection. If the user has set that boot volume group to Reduced Security and opted for it to load third-party kernel extensions, those are contained in the Auxiliary Kernel Collection, and validated by iBoot. Once the kernel and extensions collection have been loaded, the latter is locked in memory with SCIP (System Coprocessor Integrity Protection) prior to iBoot handing over to the kernel to boot.

As with T2 Macs, any failure of verification during Secure Boot should leave that Mac either in Recovery mode, or in DFU mode ready to be connected to another Mac for its firmware to be refreshed, or restored from scratch.

External boot disks

T2 Secure Boot doesn’t support booting from an external disk, which is only allowed by reducing the security setting in Startup Security Utility. When designing its M-series Macs, Apple wanted them to benefit from Secure Boot when starting up from an external disk, and incorporated this into its design.

This is implemented by the Mac always starting the boot process internally, with the LLB and iBoot being run from internal storage. Bootable external disks must have an ‘owner’ to associate them with a LocalPolicy loaded by LLB. That enables iBoot to validate the Boot Kernel Collection, SSV and other components in the external boot volume group, then to hand over to its kernel to boot macOS from that disk, instead of the internal SSD.

It took a few versions of Big Sur before this worked reliably, but this should now be robust, provided that it’s set up correctly by the user. However, it’s often incorrectly claimed that Apple silicon Macs can only start up from external disks by reducing security.

Further reading

Apple’s Platform Security Guide:
Boot process for an Intel-based Mac
Boot process for a Mac with Apple silicon
Signed system volume security

This blog:
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
Make a Ventura bootable external disk for an Apple silicon Mac
Booting macOS on Apple silicon: LocalPolicy
Ownership of Apple silicon Macs matters: how it can stop external bootable disks
Booting macOS on Apple silicon: Multiple boot disks

Which firmware should your Mac be using? (version 9, Sequoia)

This article lists the firmware versions of Macs that have been successfully upgraded to run macOS 15.0 Sequoia.

Apple doesn’t provide an official list of the current firmware versions which should be installed on each model of Mac. That displayed for Intel models uses five decimal numbers separated by dots, e.g 96.0.0.0.0, and is given below. Models with T2 chips consist of two parts, the second covering iBridge in the T2. Apple silicon Macs are different again, and give an iBoot version instead, as they don’t use EFI at all.

Macs still running older versions of macOS are covered by information at:

Apple Silicon Macs

The current iBoot version is 11881.1.1.

Intel Macs with T2 chips

The current EFI version is 2069.0.0.0.0 and iBridge is 22.16.10353.0.0,0.

Intel Mac without T2 chip

iMac: iMac19,1 2069.0.0.0.0

Apple Studio Display

The current version remains 17.0 (build 21A329).

T2 chip models:
The iMac Pro, 2019 Mac Pro, iMac 27-inch 2020, 2018 MacBook Pro with Touch Bar (MacBookPro15,1 and 15,2), 2018 Mac mini and 2018 MacBook Air, and their successor models, use a different mechanism for firmware updates, managed by their T2 chips.

How to check your Mac’s firmware version

The simplest way now is to run either of my free tools SilentKnight or LockRattler, available from their product page.

Alternatively, use the About This Mac command at the top of the Apple menu; hold the Option key and click on the System Information command. In the Hardware Overview listing, this is given as the Boot ROM Version or System Firmware Version.

What to do if your Mac’s firmware is different from that shown

If the version is higher than that given here, it indicates that Mac has installed a more recent version of macOS, which has installed a later version of the firmware. This is almost invariably the result of installing a beta-release of the next version of macOS. This occurs even when the newer macOS is installed to an external disk.

If the installed version of firmware has a version which is lower than that shown, you can try installing macOS again to see if that updates the firmware correctly. If it still fails to update, you should contact Apple Support.

Firmware updaters are now only distributed as part of macOS updates and upgrades: Apple doesn’t provide them separately.

Older versions of macOS provided the command tool eficheck at /usr/libexec/firmwarecheckers/eficheck/eficheck to check firmware version and integrity. That was removed from Sonoma. All T2 and Apple silicon models automatically check the integrity of their firmware in the early part of the boot process anyway. If any errors are found then, the Mac should be put into DFU mode and firmware restored from the current IPSW image file. In Sonoma and later this can be performed in the Finder, and no longer requires Apple Configurator 2. Full instructions are now provided in this article. If you don’t have a second Mac or don’t feel that you can perform this yourself, it should be easy to arrange with an Apple store or authorised service provider.

(Last updated 23 September 2024)

❌