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

Earlier this year, I wrote about the changes that had taken place in the System between Mojave and Sonoma 14.2.1. Now that 14.6 is out of the door and Sonoma is about to enter its two years of security-only maintenance, this article looks at how it progressed through its year as the current version of macOS. Those still running Monterey or earlier and wondering whether to upgrade now might like to take notes.

Over the last year, Sonoma has continued in the tradition of expanding the contents of the macOS System. Compared to late versions of Mojave in 2019, the number of bundles in the System library folder at /System/Library has increased by 175%, from 4,774 to 8,392, as shown in the chart below.

Steep rises in the number of bundles took place with the appearance of the boot volume group in Catalina, then again shortly before the release of the first M1 Macs, and their M3 successors in later 2023, but less so prior to the M2.

This is shown more clearly in the numbers of kernel extension bundles. New hardware often requires new kernel extensions for support, as well as their delivering architecture-specific features such as lightweight virtualisation on Apple silicon Macs. The total number of kernel extension bundles has risen from 680 in 10.15.6 to 772 in 14.6. Ironically, this is the same period over which Apple has been deprecating third-party kernel extensions, which are now decidedly uncommon on Apple silicon Macs.

Comparisons between folders within the /System/Library folder, between the last full releases of Catalina (10.15.6) and Sonoma (14.6), provide deeper insights as to just where that growth has taken place.

Greatest growth has been in Private Frameworks, which have almost doubled in number, from 2,055 to 3,803, now accounting for 45% of bundles in /System/Library. Those form the private API in macOS; public Frameworks have only risen from 600 to 772, now accounting for less than a tenth of all bundles. Thus the major increase in macOS has come in code that isn’t accessible to third-parties, only to Apple.

If you’re running a Sequoia beta, you might like to compare the figures for Extensions and the total number of bundles in /System/Library to see whether there’s any sharp increase to support the introduction of the M4 chip, or for Apple Intelligence in 15.1. I’m putting my money on the next Macs being from the M3 family, and expecting sudden rapid growth in bundles coming slightly later to support the introduction of AI.

There’s finer detail that you might have missed. During Sonoma’s year, Contact Key Verification was introduced for Messages, to ensure that your messages only reach those intended, although it requires all devices using the same Apple ID to be running recent versions of macOS/iOS/iPadOS. In lightweight virtualization, a bug was fixed that had prevented the VMs of older versions of macOS from updating with their security releases.

Among the new kernel extensions are some apparently supporting a new kernel architecture feature of Exclaves. Those include ExclaveSEPManagerProxy and ExclavesAudioKext, which might be concerned with those enhancements to virtualisation supporting the use of Apple ID in Sequoia.

Sonoma 14.4 in particular brought many new Private Frameworks, some with intriguing names include CascadeEngine, CascadeSets, Dendrite, DendriteIngest, several Poirot frameworks, SemanticPerception, and SonicKit. In other updates there were Cosmo and Tabi.

Since its release, updates to Sonoma appear to have brought mostly minor enhancements and new features, together with clearing a substantial backlog of bugs. This seems to have been a good opportunity to evolve and consolidate rather than rushing ahead with changes.

The CrowdStrike catastrophe has drawn attention to differences between modern macOS and Windows, and how kernel extensions (kexts) are being replaced in macOS by System Extensions. This article summarises what is changing, and how much progress macOS has made as of Sonoma 14.5.

Kernel space

The XNU kernel at the heart of macOS consists of central systems derived from Mach, BSD and I/O Kit. This runs at the highest level of privilege, in kernel space, often referred to as Ring 0 on Intel systems, although that term isn’t used for Arm CPUs as they have Exception Levels with EL0 as the least-privileged or user space. The kernel provides support for a great many services to interface with hardware and higher-level functions such as network protocols and file systems, that are almost entirely delivered as kexts running in Intel Ring 1.

Currently, in macOS Sonoma there are well over 650 kexts included in the System volume, three third-party kexts including SoftRAID that are in /Library/Extensions, and three that are firmlinked from outside the Signed System Volume (SSV), so they can be updated without creating a whole new sealed system snapshot.

Third-party code that needs direct access to kernel space has in the past used Kernel Programming Interfaces (KPIs) only accessible from kexts. These have included:

• I/O Kit drivers, including USB
• PCI and Thunderbolt
• Serial port drivers
• Audio drivers
• Network drivers, for network filters
• Storage drivers
• File systems.

Long and sometimes bitter experience of third-party kexts has demonstrated how their bugs and incompatibilities have resulted in kernel panics, where the kernel has no choice but to force a restart. Those risk losing data, and (in older file systems including HFS+) in leaving the file system in an unstable state, requiring repair. While recent models of Mac will restart rather than just shut down following a panic, the user needs to log back in and clean up before the Mac can be used again. When this happens at scale, as occurred with CrowdStrike, it has major impact.

User space extensions

Instead of delivering access to these features in kernel space using KPIs, macOS is transitioning to access in user space, where third-party code is delivered in System Extensions, running in Intel Ring 3 (Arm EL0). This transition involves Apple providing new and modified system kexts with their replacement interfaces for the System Extension to plug into.

One particularly relevant example is support for Endpoint Security, requiring monitoring of system events to discover potentially malicious activity. In the past this was handled by third-party kexts relying on KPIs, but should now be performed by a client System Extension that registers with Endpoint Security to receive notifications of different types of event, such as processes executing and file systems being mounted. These are documented at length, and are constrained to those events that Apple chooses to expose. If a security software developer wants access to other events, then they have to ask Apple to add them to Endpoint Security.

Deprecation and substitutes

Although Apple has been making discouraging noises about kexts for years, until it provided fully functional alternatives, developers had nowhere else to go and had to stay with kexts and KPIs. Many of those were officially deprecated in Catalina, and in Big Sur kexts using those no longer load by default. Among those affected are:

• Various KPIs now available in Endpoint Security
• Networking KPIs now available in Network Extensions
• IOHID input devices
• USB drivers now available in USBDriverKit and USBSerialDriverKit
• PCI drivers now available in PCIDriverKit and NetworkingDriverKit.

Network Extensions include changing Wi-Fi configuration, a Hotspot Helper to integrate with hotspots, VPN using built-in and custom protocols, network relaying, DNS configuration, and content filters.

Some replacements have been slower to arrive, and the following are among those made obligatory in Monterey 12.3 and later:

• Audio using AudioDriverKit
• Bluetooth using CoreBluetooth
• SCSI drivers now available in SCSIControllerDriverKit.

One of the last significant features to be transitioned to System Extensions is file system support, coming to user space in Sequoia as FSKit. Although it does now have a little documentation, that reveals that this initial release only supports simple file systems with one volume in each container; support for more sophisticated file systems is coming, but I don’t think Apple has announced when.

Penalties

Intel Macs have no restrictions or security limitations when using kexts, but Secure Boot in Apple silicon Macs won’t load any third-party kexts when run at Full Security. This makes the use of kexts on M-series Macs awkward to say the least. Apple has detailed the process of downgrading security and permitting loading of a kext, involving:

1. Start up in Recovery mode and select Options.
2. Open Startup Security Utility.
3. Downgrade boot security to Reduced Security.
4. Enable the loading of third-party kexts.
5. Restart in normal mode, and proceed to install the app with its kext installation steps, involving authorising the new kext in Privacy & Security settings.
6. Once the kext has been fully installed, and built into the Auxiliary Kernel Collection, restart.

Problems

Just as there are no clear-cut classes of app, kexts don’t all fall into neat groups. Although now widely implemented in some areas, such as Endpoint Security and Network Extensions, in others System Extensions still don’t fully replace KPIs. One good example is SoftRAID, a widely used driver supporting software RAID, which has had to be incorporated into macOS distributions as it still can’t be implemented in user space.

Kits to replace KPIs are also immature. Although I have been evaluating and reviewing products such as Little Snitch and various security suites using Network Extensions and Endpoint Security without encountering any problems, developers complain that support in macOS remains unstable and has vulnerabilities. When there’s a bug in that support, it may result in a kernel panic, causing the problem that this is intended to address.

macOS hasn’t completely replaced kexts yet, but is well on the way to achieving that. The benefits to stability and security are already being realised: I like to have a steady supply of panic logs to use in articles here, but I think the last I experienced was over three years ago, back in Big Sur, the result of a bug in iBoot firmware that has long since been fixed. Maybe I’ll have to start deliberately panicking VMs next. I’ll leave you with what used to be a common sight, lest we forget.

Thankfully, Macs weren’t affected by last week’s catastrophic CrowdStrike bug, but several of you have asked me whether macOS could be affected by something similar in the future. The short answer is that’s becoming increasingly unlikely, and for Apple silicon Macs in particular is no longer a significant risk. To understand why this is so, we need to know what happened to Windows systems with CrowdStrike protection installed, and how macOS differs.

CrowdStrike’s own account of the bug states that “an operating system crash” occurred as the result of a single logic error in one of many configuration files, known as Channel Files, that control the security protection provided by CrowdStrike’s Falcon sensor. That in turn led to the infamous Blue Screen of Death, or BSOD, the method used by Windows to inform the user that a kernel panic has occurred and the PC needs to reboot. Those configuration files are apparently automatically updated “several times a day”, without any user interaction or notification, in a long-established process used by CrowdStrike.

Researchers are currently discussing the exact point of failure and how it was able to have such serious consequences. For a single logic error to result in a kernel panic and the BSOD, it’s almost certain that the Falcon sensor runs with elevated privileges as a Kernel-Mode Driver, roughly equivalent to a kernel extension (kext) in macOS. It doesn’t seem credible that the Falcon sensor running with only user privileges would be able to bring the whole of Windows down in this way.

The macOS version of the Falcon sensor uses a kernel extension (kext) on Intel Macs prior to Big Sur, but because of the limitations of kexts on Apple silicon, it now uses an endpoint security System Extension instead.

Apple deprecated kexts years ago, and they can only be used on Apple silicon Macs if their startup security is dropped to Reduced Security and third-party kexts are explicitly allowed to load. For a vendor selling into enterprise and organisations, that requirement would be unacceptable to customers. As a result, almost all apps that used to use kexts have switched to modern System Extensions and their relatives. Those run with normal user privileges, so if they do go badly wrong shouldn’t be able to cause a kernel panic. They’re also designed to be installed and removed using the app that relies on them. If there’s a bug in a System Extension, you should be able to open its app and remove or update it from there.

When CrowdStrike for macOS started using a System Extension nearly four years ago, it even proclaimed that “reducing the need for privileged access is always a more secure approach and we are proud to embrace this new architecture.”

Apple’s road from kexts to System Extensions has been long, controversial, and only succeeded when Apple silicon Macs couldn’t use kexts without being run at Reduced Security. The devastation wrought by the CrowdStrike bug is vindication for all the pain that deprecation brought.

Where macOS remains at risk is with Apple’s own updates. Little more than eight years ago, on 26 February 2016, a silent automatic update to the macOS Incompatible Kernel Extension Configuration Data came close to breaking most Macs of the day. That list blocks old and incompatible kexts from being run, and version 3.28.1 inadvertently included one of Apple’s own kexts, that responsible for operating the Ethernet port on many Macs, including the latest models of iMacs and MacBook Pros at the time.

That didn’t cause a kernel panic, but once all those Macs had updated to the new version and restarted, their Ethernet ports vanished and couldn’t be used. That brought two serious problems: as the Ethernet port has been widely used to identify individual Macs, many apps were unable to run, and those without the fallback of WiFi networking were isolated from the Internet, so couldn’t download and install the emergency update that Apple released to fix the defective file.

Both Apple and macOS have come a long way since that happened in El Capitan. Although we all moan about bugs in macOS, quality control of macOS and security data updates has improved considerably, and updates have become much more consistent and reliable as a result of the Signed System Volume. The transition to Apple silicon is also simplifying testing and support with their more consistent hardware, compared to the gamut of different components used in Intel Macs.

As Rosyna Keller has written, this catastrophe wasn’t Microsoft’s fault but it is Microsoft’s problem. It’s a problem that Apple has addressed, and Microsoft has a lot to answer for in not making Windows more robust in the way that macOS is now. I suspect plenty of folk in Apple are feeling rather smug.

Summary

• The CrowdStrike catastrophe occurred because a single logic error in a configuration file for its Falcon sensor escalated into a kernel panic.
• This almost certainly occurred because the Falcon sensor runs with elevated privileges, in kernel space rather than user space.
• Apple has almost eliminated third-party kernel extensions from macOS, replacing them with System Extensions running in user space. That has removed their propensity to cause kernel panics. In recent macOS, CrowdStrike’s Falcon sensor runs in user space as a System Extension.
• Remaining risks of kernel panics are in macOS updates, which Apple has improved considerably to reduce risk.
• Microsoft needs to remove third-party drivers from kernel space if Windows is to be more resilient to this type of failure.