Managing kernel extensions

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.

Further reading

Installing a kernel extension (Apple)
Installing system extensions and drivers (Apple)