Like opiates, kernel extensions have brought wonderful powers, but all too frequent suffering. Any feature which can transform a Mac into an incipient kernel panic isn’t exactly endearing. I suppose in some ways I’ve benefitted from the adverse effects of third-party kernel extensions (kexts) for the last twenty-one years, in all the problem-solving articles I’ve written about them. I’m still looking forward to kextermination, the time when kexts are finally banished from macOS.

No, this doesn’t mean that I’ve got inside information that Apple is going to announce at WWDC that macOS 13 on Apple Silicon won’t allow the loading of third-party kexts, although I’d be delighted if that were to happen. Instead, as more and more Mac users migrate to these new Macs, kexts become ever rarer. I have eight third-party kexts on this iMac Pro, and not one on any of my M1 Macs.

If you’re still waiting for your M1 Mac to be released from China’s strangulating lockdowns, you may not be aware of the surprise that’s in store for you if you want it to load a third-party kext. First, the entry qualifications are stringent: it has to be signed using a special certificate provided by Apple, it has to be notarized, and must contain complete executable code for ARM chips, as it can’t use Rosetta 2 translation to accommodate Intel code.

Installing the kext is also non-trivial. Apple’s advice to developers is lengthy, and should be sufficient deterrent in itself. For M1 Macs, the crucial opening steps can’t be automated, and require the user to:

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 the Security & Privacy pane.
6. Once the kext has been fully installed, and built into the Auxiliary Kernel Collection, to restart.

Although Apple advises developers to provide “a clear explanation of what your kext does, and why its installation is necessary” to alleviate some of the user’s concerns, particularly in reducing security, that might be a lost cause for many. One of the most significant penalties of running your M1 Mac at that level of security is that Activation Lock is disabled, making it possible for someone else to erase, restore and activate it for themselves. Apple Pay capabilities could also be disabled if macOS considered that a third-party kext could interfere with the trustworthiness of macOS. Some users report that copies of macOS which have been downgraded to allow kext use don’t update reliably, and can exhibit other problems.

Reducing the security of an M1 Mac isn’t disaster, but it’s clearly not something to enter into lightly.

Installing kexts in the past was so easy that we forget why most of them are there any more. Of the eight on my iMac Pro, the oldest dates from 2013, and I’m not aware that any of them is actually needed any more. But they’ve quietly migrated from Mac to Mac over the last few years as kexts usually do. Thankfully, none of them seems to have affected the stability of this Mac, but that might be because none of them are loaded anyway.

If you’re reliant on a third-party kext and have an M1 Mac, you have my sympathy. There’s no easy solution when there isn’t a modern replacement such as a system extension, and that’s hard when you still need to support older hardware. I don’t have a good answer yet for what I’m going to do with my old Promise Pegasus RAID system, for which I still have several sets of hard disks containing old backups. As the kexts to support that hardware are now unsupported and Intel-only, I’m probably going to have to retain an old Intel Mac in case I ever want access to them.

However, macOS can’t go on indefinitely supporting old kexts, even those that are now available with ARM-native code. The constraints on the kernel to do this, and the continuing toll of kernel panics and other problems, simply can’t justify it. As with other changes like the demise of optical disk drives, we’ll undergo a short period of pain, following which we’ll all be the better.

There are still some kexts whose importance merits special attention. Among them is SAT SMART, which gives access to S.M.A.R.T. health data on external disks connected via USB. If Apple isn’t prepared to do the decent thing and incorporate this facility into macOS, then the community needs to organise a modern replacement extension.

Then bring on kextermination. It’s long overdue and can only do our Macs a power of good.

Postscript

Several have questioned where Apple states that Activation Lock is disabled when an M1 Mac is running at Reduced Security. The answer is here, where Apple states the requirements for Activation Lock on an M1 Mac are two-factor authentication for Apple ID, and that “the security policy must be set to Full Security, the default setting”. Additional requirements implicit in what is stated earlier in that article are that Find My Mac must be turned on for that Mac (“Activation Lock remains enabled as long as you keep Find My turned on”) and that the Mac remains signed in to iCloud (“Find My also turns off when you sign out of iCloud”).

Of course Apple might have changed this without updating that article, but at present that is the most definitive information that is available. Formally testing Activation Lock to demonstrate whether this still works when any of those conditions isn’t met is non-trivial.

If you’re unsure of the differences between kernel extensions and modern replacements such as system extensions, then you should find this article informative. The key sentence there is: “Most importantly for M1 Mac users, they don’t need macOS to be run at reduced security, nor approval in the Security & Privacy pane.”

If you still think that running your M1 Mac at Reduced Security with third-party kernel extensions loading is fine, then you should consider carefully Apple’s statement in its Platform Security Guide: “Important: Kexts are no longer recommended for macOS. Kexts risk the integrity and reliability of the operating system and Apple recommends users select solutions that don’t require extending the kernel.” [The emphasis is in the original.]