If, like me, you pay close attention to firmware updates released with macOS, you may have noticed something highly unusual if not unique this week, in the firmware updates that came with macOS Sequoia 15.2, Sonoma 14.7.2 and Ventura 13.7.2: those could mark the end of an era.
All new Macs since Apple transitioned to using Intel processors have one of three classes of firmware:
Intel Macs without a T2 chip only have EFI firmware, whose version reads something like 529.140.2.0.0. These are model-specific.
Intel Macs with a T2 chip have firmware for both their Intel systems in EFI, and iBridge for the T2, giving them a double firmware version like 2069.40.2.0.0 (iBridge: 22.16.12093.0.0,0). All models with a T2 chip can run the same EFI and iBridge versions.
Apple silicon Macs have iBoot, with a version like 11881.61.3, which is common across all models.
This complexity was the reason for my first developing EFIcienC, predecessor to SilentKnight, compiling and maintaining databases of firmware versions, and trying to help those whose Macs stubbornly refused to update their EFI firmware when they should have done. This site still has long lists of the latest firmware versions for Macs running Catalina, for example.
As the number of supported Intel Macs without a T2 chip has steadily fallen, what used to be a long and complex list has shrunk to just seven models. With the release of macOS Sequoia 15.0, Sonoma 14.7 and Ventura 13.7, Apple stopped updating the EFI firmware for Intel Macs without T2 chips, which are now frozen as they were last June and July.
When Apple released Sequoia 15.2, Sonoma 14.7.2 and Ventura 13.7.2 this week, it appears to have ceased updating the EFI firmware in Intel Macs with T2 chips.
T2 models were updated to EFI 2069.0.0.0.0 and iBridge 22.16.10353.0.0,0 when Sequoia 15.0 was released on 16 September 2024. No firmware updates came in the rapid update to 15.0.1, but in 15.1 those models were updated to EFI 2069.40.2.0.0 and iBridge 22.16.11072.0.0,0.
Sequoia 15.1.1 also didn’t bring any change in firmware, and 15.2 updates T2 models to EFI 2069.40.2.0.0 and iBridge 22.16.12093.0.0,0: while the T2’s firmware has been updated, no change has been made in the EFI version. As far as I’m aware that’s the first time that has happened since the initial releases of T2 firmware at the end of 2017 and early 2018. The first record I have of their version numbers is of EFI 1037.147.1.0.0 and iBridge 17.16.16065.0.0,0, since when they have come a very long way.
While I’m sure that Apple could still update EFI firmware if necessary, I think we have seen the last planned updates, with only iBridge for the T2 and iBoot for Apple silicon Macs to continue to advance with future releases of macOS. As the T2 is also Apple silicon, that means an end to the last firmware for Intel processors, after more than 18 years. The end of an era indeed, and time to pour one out for EFI firmware in Macs.
I wouldn’t like to hazard a guess at how much longer Apple will continue to support iBridge firmware for T2 chips. Firmware updates aren’t a required part of macOS updates, and most Macs cease to enjoy them well before they’re updated to their last macOS.
Activity Monitor is one of the unsung heroes of macOS. If you understand how to interpret its rich streams of measurements, it’s thoroughly reliable and has few vices. When tuning for performance, it should be your starting point, a first resort before you dig deeper with more specialist tools such as Xcode’s Instruments or powermetrics.
How Activity Monitor works
Like Xcode’s Instruments and powermetrics, the CPU view samples CPU and GPU activity over brief periods of time, displays results for the last sampling period, and updates those every 1-5 seconds. You can change the sampling period used in the Update Frequency section of the View menu, and that should normally be set to Very Often, for a period of 1 second.
This was normally adequate for many purposes with older M-series chips, but thread mobility in M4 chips can be expected to move threads from core to core, and between whole clusters, at a frequency similar to available sampling periods, and that loses detail as to what’s going on in cores and clusters, and can sometimes give the false impression that a single thread is running simultaneously on multiple cores.
However, sampling frequency also determines how much % CPU is taken by Activity Monitor itself. While periods of 0.1 second and less are feasible with powermetrics, in Activity Monitor they would start to affect its results. If you need to see finer details, then you’ll need to use Xcode Instruments or powermetrics instead.
% CPU
Central to the CPU view, and its use in tuning for performance, is what Activity Monitor refers to as % CPU, which it defines as the “percentage of CPU capability that’s being used by processes”. As far as I can tell, this is essentially the same as active residency in powermetrics, and it’s vital to understand its strengths and shortcomings.
Take a CPU core that’s running at 1 GHz. Every second it ‘ticks’ forward one billion times. If an instruction were to take just one clock cycle, then it could execute a billion of those every second. In any given second, that core is likely to spend some time idle and not executing any instructions. If it were to execute half a billion instructions in any given second, and spend the other half of the time idle, then it has an idle residency of 50% and an active residency of 50%, and that would be represented by Activity Monitor as 50% CPU. So a CPU core that’s fully occupied executing instructions, and doesn’t idle at all, has an active residency of 100%.
To arrive at the % CPU figures shown in Activity Monitor, the active residency of all the CPU cores is added together. If your Mac has four P and four E cores and they’re all fully occupied with 100% active residency each, then the total % CPU shown will be 800%.
There are two situations where this can be misleading if you’re not careful. Intel CPUs feature Hyper-threading, where each physical core acquires a second, virtual core that can also run at another 100% active residency. In the CPU History window those are shown as even-numbered cores, and in % CPU they double the total percentage. So an 8-core Intel CPU then has a total of 16 cores, and can reach 1600% when running flat out with Hyper-threading.
The other situation affects Apple silicon chips, as their CPU cores can be run at a wide range of different frequencies according to control by macOS. However, Activity Monitor makes no allowance for their frequency. When it shows a core or total % CPU, that could be running at a frequency as low as 600 MHz in the M1, or as high as 4,512 MHz in the M4, nine times as fast. Totalling these percentages also makes no allowance for the different processing capacity of P and E cores.
Thus an M4 chip’s CPU cores could show a total of 400% CPU when all four E cores are running at 1,020 MHz with 100% active residency, or when four of its P cores are running at 4,512 MHz with 100% active residency. Yet the P cores would have an effective throughput of as much as six times that of the E cores. Interpreting % CPU isn’t straightforward, as nowhere does Activity Monitor provide core frequency data.
In this example from an M4 Pro, the left of each trace shows the final few seconds of four test threads running on the E cores, which took 99 seconds to complete at a frequency of around 1,020 MHz, then in the right exactly the same four test threads completed in 23 seconds on P cores running at nearer 4,000 MHz. Note how lightly loaded the P cores appear, although they’re executing the same code at almost four times the speed.
Threads and more
For most work, you should display all the relevant columns in the CPU view, including Threads and GPU.
Threads are particularly important for processes to be able run on multiple cores simultaneously, as they’re fairly self-contained packages of executable code that macOS can allocate to a core to run. Processes that consist of just a single thread may get shuffled around between different cores, but can’t run on more than one of them at a time.
Another limitation of Activity Monitor is that it can’t tell you which threads are running on each core, or even which type of core they’re running on. When there are no other substantial threads active, you can usually guess which threads are running where by looking in the CPU History window, but when there are many active threads on both E and P cores, you can’t tell which process owns them.
You can increase your chances of being able to identify which cores are running which threads by minimising all other activity, quitting all other open apps, and waiting until routine background activities such as Spotlight have gone quiet. But that in itself can limit what you can assess using Activity Monitor. Once again, Xcode Instruments and powermetrics can make such distinctions, but can easily swamp you with details.
GPU and co-processors
Percentages given for the GPU appear to be based on a similar concept of active residency without making any allowance for frequency. As less is known about control of GPU cores, that too must be treated carefully.
Currently, Activity Monitor provides no information on the neural processing unit (ANE), or the matrix co-processor (AMX) believed to be present in Apple silicon chips, and that available using other tools is also severely limited. For example, powermetrics can provide power use for the ANE, but doesn’t even recognise the existence of the AMX.
Setting up
In almost all cases, you should set the CPU view to display All processes using the View menu. Occasionally, it’s useful to view processes hierarchically, another setting available there.
Extras
Activity Monitor provides some valuable extras in its toolbar. Select a process and the System diagnostics options tool (with an ellipsis … inside a circle) can sample that process every millisecond to provide a call graph and details of binary images. The same menu offers to run a spindump, for investigating processes that are struggling, and to run sysdiagnose and Spotlight diagnostic collections. The Inspect selected process tool ⓘ provides information on memory, open files and ports, and more.
Explainers
Residency is the percentage of time a core is in a specific state. Idle residency is thus the percentage of time that core is idle and not processing instructions. Active residency is the percentage of time it isn’t idle, but is actively processing instructions. Down residency is the percentage of time the core is shut down. All these are independent of the core’s frequency or clock speed.
When an app is run, there’s a single runtime instance created from its single executable code. This is given its own virtual memory and access to system resources that it needs. This is a process, and listed as a separate entity in Activity Monitor.
Each process has a main thread, a single flow of code execution, and may create additional threads, perhaps to run in the background. Threads don’t get their own virtual memory, but share that allocated to the process. They do, though, have their own stack. On Apple silicon Macs they’re easy to tell apart as they can only run on a single core, although they may be moved between cores, sometimes rapidly. In macOS, threads are assigned a Quality of Service (QoS) that determines how and where macOS runs them. Normally the process’s main thread is assigned a high QoS, and background threads that it creates may be given the same or lower QoS, as determined by the developer.
Within each thread are individual tasks, each a quantity of work to be performed. These can be brief sections of code and are more interdependent than threads. They’re often divided into synchronous and asynchronous tasks, depending on whether they need to be run as part of a strict sequence. Because they’re all running within a common thread, they don’t have individual QoS although they can have priorities.
In case the message isn’t clear yet, third-party kernel extensions are on their way out, particularly in Apple silicon systems. Although macOS continues to extend the capabilities of its kernel using nearly 700 of them, for almost all purposes user apps and devices should now have switched to using modern system extensions and their equivalents. This article considers how you can clean your Mac of those old kernel extensions (kexts), particularly in preparation for a new Mac.
The problem
In the past kexts have been used widely to support third-party hardware and features like software firewalls and security protection. Because those run at a highly privileged level, in what’s known as Ring 1, they have been a well-known cause of instability leading to kernel panics. They also provide malicious software with an opportunity to wreak havoc at the highest level. Replacing kexts with system extensions run at a user level should improve both stability and security, although experience shows that the first of those isn’t yet guaranteed, as macOS support for system extensions hasn’t been as free of bugs as it should have been, and sometimes has caused kernel panics.
From Big Sur onwards, the previous scheme of prelinked kernels has changed to use kext collections pooling kexts to be loaded into one of three:
The Boot Kext Collection (BKC), on the Sealed System Volume in /System/Library/KernelCollections (Intel Macs) or the Preboot volume (M-series Macs). This is the equivalent of the old prelinked kernel, and contains the kernel itself, and all the major system kernel extensions required for a Mac to function. This is typically about 65 MB in size on Intel.
The System Kext Collection (SKC), also on the Sealed System Volume of Intel Macs in /System/Library/KernelCollections, but not used on Apple silicon models. This contains other system kernel extensions, loaded after booting with the BKC, and typically around 370 MB.
The Auxiliary Kext Collection (AKC), stored on the Data volume in /Library/KernelCollections when it exists, is built and managed by the service kernelmanagerd. This contains all installed third-party kernel extensions, and is loaded after the other two. In Full Security mode on Apple Silicon there’s no AKC.
Cleaning up old kexts is a valuable move even if you’re not intending to migrate to an Apple silicon Mac, and has grown in importance with newer Macs. For a kext to be used on an Apple silicon Mac its boot security has to be reduced, third-party kexts must be enabled, and each one installed with authorisation through Privacy & Security settings, something you’ll probably want to avoid.
Uninstalling kexts
Before going any further, you need to check each of the kexts installed on your Mac to ensure that it can now be safely removed, either because there’s a better substitute, or because they have simply become orphaned. In many cases, on older Macs, kexts currently installed aren’t used at all, but have been abandoned there.
As you may be aware, kexts are now found in two different locations. They should have been originally installed by the app they came with, and saved first to /Library/Extensions. macOS then normally copies them from there to a folder nested inside /Library/StagedExtensions. That presents a further problem, as the latter are protected by SIP and can’t be tampered with. Cleaning up old kexts might thus appear an impossible task.
The good point about /Library/StagedExtensions is that its contents are structured to inform you of where the original kext came from: if it’s in /Library/StagedExtensions/Applications, then the kext was installed by that app, otherwise its folder path should lead you in the right direction.
For kexts installed by an app, or its installer, the responsibility for removing that kext rests with the app or its dedicated uninstaller. Apps that use kexts have to install them before use, for which most run scripts to move or copy the kext into the /Library/Extensions folder. They will then use additional scripts to update or remove that kext, that should save you the trouble. First visit that app’s support pages, and consult the procedure described there for uninstalling it. If the copy you have installed on your Mac isn’t the current version, you are likely to be advised to update to that latest version in order to uninstall it correctly.
Orphaned kexts
When a kext appears to have become orphaned from its app, or perhaps was installed independently, you’ll need to remove it manually. The steps required are:
Delete all apps and services that might try to use that kext, and any other kexts that might depend on it.
Unload the kext.
Delete the kext from the /Library/Extensions folder.
Restart to allow the auxiliary kext collection to be rebuilt.
It’s important to remove the app and any services that might try using that kext, as some might even try to reinstall it if they’re run. Others that might be run from LaunchAgents or LaunchDaemons could get into difficulties without the kext. Good uninstall scripts should deal with this thoroughly without you having to resort to looking for yourself.
Kexts are now unloaded using a command of the form sudo kmutil unload -b [bundle-identifier]
or sudo kmutil unload -p [bundle-path]
where bundle-identifier is a reverse URL like com.highpoint-tech.kext.HighPointRR, or the bundle-path is similar to /Library/Extensions/HighPointRR.kext. kmutil is the replacement for the old kextunload command. Although you could still use the latter, it will merely call kmutil to do its work.
With the kext unloaded, you can then delete it from its accessible location in /Library/Extensions. macOS controls its own staged copy in /Library/StagedExtensions, which it ultimately may get around to removing as well. If you want to remove all kexts from the staging directory, use the command sudo kmutil clear-staging
although that will also clear any that you might still need, and could require those to be reinstalled.
With those cleared away, you’re ready to restart, which should trigger macOS to rebuild the auxiliary kext collection containing third-party kexts before they’re loaded during the restart. If the auxiliary kext collection isn’t rebuilt correctly, you can force that with the command sudo kmutil rebuild
and authorising that, followed by restarting the Mac to bring those changes into effect.
You can then check to see if that kext has been loaded using the command kmutil showloaded --collection aux
to list all loaded kexts in the auxiliary kext collection.
Migration to Apple silicon
Not only is Migration Assistant reluctant to try installing kexts on your new Mac, because of their requirements for use on Apple silicon Macs, it’s unable to enable and load any kexts. However, if you do need to use kexts on an M-series Mac, you’re going to have to enable them first using Startup Security Utility in Recovery Mode, then run the app’s install sequence and authorise them in Privacy & Security settings. That isn’t something that can happen behind your back, and without changing boot security settings no third-party extensions can be loaded. By default, your new Mac should start as clean as a whistle.
Summary
This is a good time to clean up old kernel extensions on your Mac.
Where possible, follow instructions for their removal provided on their support site.
Use an app’s uninstall feature, or its uninstaller, if provided.
Manual uninstalls require deletion of apps and code relying on that kext, unloading using kmutil, deletion from /Library/Extensions, and restarting.
Don’t worry about what may be left behind in /Library/StagedExtensions.
Old kexts can’t be enabled automatically by Migration Assistant for an Apple silicon Mac.
Macs have used four different architectures for their Central Processing Units over the last 40 years. From their launch by Steve Jobs on 24 January 1984, for the first decade they used Motorola 68K CPUs, then switched to PowerPCs designed by an alliance of Apple, IBM and Motorola, which were used for 12 years. After 14 years being built around Intel processors from 2006, Macs most recently changed a third time to use Apple’s own Arm-based chips.
Over those 40 years, continuous improvements in capabilities and performance of CPUs have transformed Mac OS and the apps it supports.
Motorola 68K
CPUs execute instructions in synchrony with a clock whose frequency determines the rate of instruction execution. The Motorola 68000 processor in the original Mac 128K ambled along at a clock speed of just 8 MHz. The last 68K models featuring 68040 CPUs had raised that to 33 MHz, and added specialist Memory Management Units (MMUs) and floating point units. The latter first appeared as 68881 and 68882 maths co-processors, but were later integrated into the 68040.
MMUs were particularly important for the implementation of virtual memory. When the Macintosh II was introduced in 1987, it was the first Mac that could be fitted with Motorola’s optional 68851 paged MMU, required for it to run Apple’s A/UX port of Unix with virtual memory support. Strangely, Apple’s own MMU fitted in the standard Mac II didn’t support virtual memory. Its 68020 CPU was also the first in Macs to use 32 bits rather than the 16 of the original 68000.
AIM PowerPC
When introduced in 1994, the first Power Macs came with PowerPC 601 or 601+ CPUs running at frequencies up to 110 MHz, nearly 14 times faster than the original Mac 128K. Just over a decade later, the last Power Mac G5 raised that to dual two-core CPUs at 2,500 MHz, more than 20 times the clock frequency, and the previous model had offered dual 2,700 MHz CPUs.
PowerPCs had their origins in IBM’s high-end POWER architecture based on a reduced instruction set (RISC) intended to be run at higher frequencies. Initially, these CPUs used a 32-bit design, but progressed to 64 bits. Not only do they have integrated floating point units that were extended for Apple, but later models include AltiVec vector processing for single-precision floating point and integer operations.
High CPU frequencies bring higher power consumption and heat output. A dual-core G5 with a PowerPC 970MP CPU used a maximum of 100 W at 2,000 MHz, and some of the last G5 Macs used liquid cooling to cope with the heat generated at higher frequencies. Those didn’t prove long-lived, with coolant leaks a common and fatal failing.
Intel x86
In early 2006 Apple started releasing its new range of Macs using Intel CPUs. With the exception of a base model of Mac mini, those came with 2-core Core Duo processors running at up to 2 GHz, and were soon followed by the first Mac Pros featuring two 64-bit 2-core Xeon 5100 CPUs (Woodcrest) at up to 3 GHz. By the following year, the first 8-core Mac Pro was available.
Earlier increases in CPU frequency gradually petered out. The last Intel Mac Pro was available with cores running at 2.5-3.5 GHz, boosted to a maximum of up to 4.4 GHz. Instead, high-end models offered as many as 28 cores and drew power up to 900 W. More typical of late desktop Macs were Intel Core i9 CPUs with 6-8 cores at similar frequencies. Adding more processor cores has been an effective way to run more code at the same time. Tasks are divided into threads that can run relatively independently of one another. Those threads can then be distributed across several CPU cores.
Rising power consumption and heat output were becoming even more of a problem in MacBook Pro models.
Apple Arm
Well before Apple had joined IBM and Motorola in the AIM alliance, it had co-founded the company based in Cambridge, England, that was to become ARM (for Acorn RISC Machines). Its RISC processor was used in Apple’s Newton MessagePad of 1993, and in 2010 Apple released its first iPhone and iPad designed around a single-core 32-bit Arm CPU running at a cool and economical 1 GHz.
From before macOS Mojave in 2018, Apple was preparing for its next migration, to its own integrated Systems on a Chip (SoC), starting with the M1 in 2020. The first iPhone to incorporate two CPU core types was the iPhone 7 of 2016, in its A10 Fusion SoC. Rather than simply adding more cores, Apple had adopted the Arm big.LITTLE architecture, in which background threads are run on slower, more efficient CPU cores, and higher priority user processes run on faster, more performant cores.
The first two families of M1 and M2 chips have cores grouped in clusters of no more than 4, but Apple increased cluster size to 6 in the M3 and M4. While the M1 family consists of two designs, one for the base variant, and the second for both Pro and Max, and doubled in the Ultra, M3 and M4 families have distinct designs for their Pro and Max variants. For the M4, this offers a full range from 8 to 16 cores in total, with an anticipated Ultra extending to 32. In addition to CPU cores with built-in vector processing (NEON), these chips incorporate specialist co-processors such as a neural engine and a proprietary matrix co-processor, AMX.
Performance (‘big’) cores have increased in maximum frequency, from 3.2 GHz in the M1 to 4.5 GHz in the M4 four years later.
Trends
The period 1984-2007 was dominated by increasing CPU frequency, as demonstrated in the two charts below.
This chart uses a conventional linear Y axis to demonstrate that frequency rose rapidly during the decade from 1997. As the form of this curve is S-shaped, the chart below shows the same data with a logarithmic Y axis.
Since about 2007, Macs haven’t seen substantial frequency increases. Many factors limit the maximum frequency that a processor can run at, including its physical dimensions, but among the most significant in practical terms are its power requirements and heat output, hence its need for cooling. Thus, the period 2005-2017 became dominated by increasing core count.
This chart shows how the number of processors and cores inside Macs didn’t start rising until around 2005, just as frequencies were topping out. Thus, many of the CPU performance improvements from 2007 onwards have been the result of providing more cores. But there’s a practical limit as to how many of those cores will get used, which is where processing more data becomes important, as it has from 1998 onwards.
It’s remarkable how much of Mac OS has survived if not flourished over those 40 years that our Macs have gone from a pedestrian Motorola 68000 processor to the 12 performance cores capable of 4.5 GHz in an M4 Max chip.
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.
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:
Boot ROM, which verifies the Low Level Bootloader (LLB).
LLB, sometimes described as the first stage, concerned with loading and booting some auxiliary cores, security policy, and verifying the second stage, iBoot.
iBoot, which continues validations and verifications, including signatures and root hash of the SSV, before handing over to the kernel.
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.
Login
