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.