Some apps, like SoftRAID and Little Snitch, rely upon kernel extensions (KEXTs) to be able to work. Although Apple has been discouraging developers from using these extensions, their substitutes such as System Extensions (SEXTs) have only recently been introduced, and it’s by no means clear whether they can offer the same features for developers.
At the same time, macOS Catalina has become increasingly restrictive on third-party kernel extensions, and there have been bugs which have caused problems. This article summarises what you can do when you need to run an app which relies on kernel extensions but falls foul of Catalina.
How to tell if an app relies on kernel extensions
First check its documentation and support pages. Recent and properly supported apps which use kernel extensions should now make this clear, and explain how to install them in Catalina.
If you’re still unsure, you can open the app/installer and look for yourself. If supplied as an installer package, double-clicking that package will open it in the Installer app, where you can view a list of the items it installs. Look for anything named with the .kext extension to be placed inside the app itself, or in an Extensions folder. In an app, select the app and use the Finder’s Show Package Contents command to open it. Look in the Resources folder inside Contents, for items with the .kext extension.
Follow the installation instructions
Unless this version of the app was released some time ago, it should come with an explanation of how to ensure its kernel extension(s) are correctly installed in Catalina. Normally, this requires you to run the app (or its installer), during which it and macOS should prompt you to open the General tab of the Security & Privacy pane, authenticate, and agree to the kernel extension being installed. This consent is only available for a relatively short time: if it occurs when you’re out, it’s possible that it will vanish, and you may have to repeat the process to catch it. This is what Apple calls User-Approved Kernel Extension Loading, and doesn’t involve the Privacy tab, with which you’re probably now more familiar.
What if that doesn’t work?
Sometimes, even after closing the app or installer and restarting, the kernel extension doesn’t get installed properly. You can repeat the process, maybe even a couple of times, restarting after each attempt. But in some cases – in Macs with a T2 chip only – the kernel extension won’t load properly unless you disable Secure Boot.
To do that, you’ll need to restart into Recovery mode. Once its main window is displayed, open Startup Security Utility from the Utilities menu. After authenticating as an admin user, its window will appear, where you should select the No Security item (the lowest of the three) in the Secure Boot section. Unless you want to start up from an external volume, you don’t need to change the lower section of Allowed Boot Media.
Once you’ve done that, restart your Mac normally, using the Restart command in the Apple menu. You should then be able to install the kernel extension in the normal way, with User-Approved Kernel Extension Loading.
What you then don’t know is whether it’s safe to go back into Recovery mode and turn Secure Boot back on. The only way to find out (other than from the app’s support pages) is to try it. If when you go back to Secure Boot the app behaves as if the kernel extension hasn’t been installed, then you know that you can only run that app with Secure Boot disabled.
As you’re using Catalina with its read-only System volume, running with Secure Boot turned off isn’t as secure as with it on. However, these two security features do overlap quite a bit, and disabling Secure Boot in Catalina isn’t as risky as it would be in Mojave or earlier. It’s an unfortunate choice which you may have to make, though, until these issues with kernel extensions are properly resolved between Apple and third-party developers.
Why all the problems?
These mainly arise because of Apple’s ever-increasing security measures and the way in which kernel extensions are loaded. Old versions of Mac OS X used to load kernel extensions from the respective Extensions folders soon after the kernel itself had loaded, but this makes startup extremely slow. The solution now used by macOS is to build a prelinked kernel with all its extensions already in place. This is a complex task performed by the
kextcache command tool, and was tricky enough before the introduction of Catalina’s read-only System volume.
Once a new prelinked kernel has been built, it has to be installed in the folder /System/Library/PrelinkedKernels/prelinkedkernel, which is now on the read-only System volume. This task is performed by a shell script named
shove_kernels, which can only run on two occasions: during a macOS install or update, when the System volume is accessible, and for a brief moment during system shutdown, when all other processes have been terminated. If that latter opportunity fails, then the prelinked kernel containing the newly installed extension can’t be installed, and won’t be used.
One trick which could in theory solve the problem of install failures is to install the kernel extension and immediately apply the latest Catalina update: that could trick the installer to build the new extension into its prelinked kernel and copy that onto the System volume successfully. However, I haven’t seen any reports of anyone trying this yet.
This could get worse before it gets better
Apple has started beta-testing macOS 10.15.4, which is due for release in a couple of months, probably in late March. Apple has just informed developers that many of the existing interfaces used in kernel extensions will be deprecated in that release, and their use will result in a prompt for the user to contact the extension’s developer.
If you rely on third-party software which in turn needs kernel extension(s) to work, you may find those run into problems in 10.15.4, and should delay updating to it until the developer has advised you that is safe and their extension(s) will still function properly, or they provide an update to address any issues. It’s likely that 10.15.4 will continue to support existing kernel extensions and only apply these new rules to more recent versions, but Apple hasn’t made this clear yet.
I will try to keep you updated with news of further developments.