With Apple announcing that Kernel Extensions will be deprecated at Worldwide Developers Conference (WWDC) 2019, we can expect a lot of changes coming to macOS. In this guide, we’re going to take a look at some of the latest developments concerning KEXTs (Kernel Extensions), KPIs (Kernel Programming Interfaces), how System Extensions are replacing them, and how macOS Catalina is phasing them out.
Here’s an overview of what we’ll cover:
- What’s Replacing macOS Kernel Extensions?
- Confusion Around Catalina Dialogue Boxes
- What’s a System Extension Profile?
What’s Replacing macOS Kernel Extensions?
Kernel Extensions, sometimes referred to as KEXTs, let developers load code directly into the macOS kernel. By giving developers access to the kernel, which is in charge of everything on the system, Kernel Extensions leverage their “kernel privileges” to create very powerful apps.
But this has some downsides. While Kernel Extensions give developers the freedom to make apps with powerful and complex functions (such as virtualization applications like Parallels, which can run Windows OS within macOS simultaneously), it also presents them with challenges in terms of development, security, and stability.
But this is starting to change. In macOS 10.15 Catalina, Apple released two new frameworks: the DriverKit framework and the SystemExtension framework. Beyond expanding the safety and stability of macOS, these frameworks are being used as userspace alternatives to Kernel Extensions, gradually replacing KEXTs. We’ll take a closer look at the challenges of KEXTs and the solutions that System Extensions offer in this section. (And for more information about the new frameworks, see our guide to the Apple endpoint security framework.)
For the latest information on KEXTs in Big Sur, you can read the "Changes to Kernel Extensions" section of our guide to Big Sur.
Challenges with macOS Kernel Extensions
We mentioned earlier that Kernel Extensions could run into some security and stability problems — let’s talk about why. Because the actions taken by Kernel Extensions occur within the kernel, they’re prioritized over every other function in the system. While this unlocks a lot of freedom for developers, it also creates a risky environment to develop and debug apps in. There’s just no room for error — even a minor bug could freeze or panic the system.
Beyond the stability challenges that Kernel Extensions present developers while creating apps, the power of KEXTs also creates some security concerns. We’ve already talked about how running in the kernel gives Kernel Extensions advanced capabilities and prioritizes them over other system functions — but we haven’t made it clear how far this power goes.
Since one of the kernel’s most important jobs is to define and enforce security policies, and Kernel Extensions run within it, KEXTs aren’t bound to the macOS security policies. So, if a Kernel Extension happens to have a bug that leaves it vulnerable to being compromised by malicious actors, it isn’t just the app at risk — it’s the whole system. And there’s no security policy that can restrain it.
To remedy these issues, Apple introduced System Extensions, which provide some similar capabilities to KEXTs, only in a much more controlled environment. We’ll see how these match up with KEXTs next.
What to Know About System Extensions
Introduced in macOS 10.15 Catalina, System Extensions let developers create apps that extend the functionality of macOS — without requiring kernel-level access. By leaving the kernel, System Extensions avoid some of the issues with KEXTs that we just mentioned, letting developers:
- Develop apps in userspace: While the developing apps in the kernel was restrictive and demanded precision, developing in userspace is a lot more forgiving. With System Extensions, minor bugs won’t lead to kernel-panics or unpredictable system behavior, and developers don't need to worry about managing dynamic memory allocation, synchronization, and latency.
- Develop with more frameworks and languages: When it came to using Kernel Extensions, developers were limited to using one framework — and they could only write code in C or C++. This isn’t so with System Extensions. Now, developers can use any macOS SDK framework, and they can write code in any programming language (with the exception of driver extensions, which still must be written in C or C++ and use the DriverKit framework).
Most importantly, System Extensions are a big step up in terms of security. Remember how we talked about security policies not applying to macOS Kernel Extensions? By being privileged over all other system behaviors, buggy KEXTs could leave the entire Mac vulnerable to becoming compromised or controlled.
But because System Extensions run in userspace (instead of the kernel), they don't have unfettered kernel-level control. They just run like an app would — so the consequences of bugs won’t affect the entire system, just the software that the system extensions are a part of.
More than that, because System Extensions run in userspace, they’re subordinate to the system’s security policies. This takes the main security vulnerability that KEXTs possessed out of the picture, all while increasing the stability of the system. But that doesn’t mean System Extensions lack power.
While they can’t perform kernel-level functions, they do have some advanced permissions to do things like use APIs (application programming interfaces) to communicate with the kernel or have direct access with associated hardware devices.
It bears repeating that System Extensions are all part of an effort by Apple to phase out the use of KEXTs and create a more stable and secure environment for macOS. For now, a complete transition to System Extensions isn’t possible; some KEXTs that use KPIs (Kernel Programing Interfaces) that do not yet have System Extension alternatives are still needed for some operations. However, System Extensions should be used in place of KEXTs wherever possible.
Confusion Around Catalina Dialogue Boxes
There’s been some confusion around certain dialogue boxes that appear in macOS Catalina. As Apple states in their support documentation: “In macOS 10.15.4, use of deprecated KPIs triggers a notification to the user that the software includes a deprecated API and asks the user to contact the developer for alternatives.”
As we mentioned earlier, it’s Kernel Extensions and the KPIs they use that are being deprecated — System Extensions are being phased in as alternatives. Even so, these dialogue boxes tell users that the program they wanted to run is using a legacy System Extension, though it is actually picking up on a Kernel Extension using a deprecated KPI. You can see this in the image below:
If you aren’t sure if your software is using a System Extension or a Kernel Extension, there are a few things you can do to find out that we will cover in the next few sections. In the next section, we’re going to go over a list of the KPIs that Apple has deprecated (along with their System Extension alternatives), and then we’ll see how you can use a couple of Terminal commands to get information on Kernel Extensions or System Extensions that may be running on your Mac.
Deprecated KPIs and their System Extension Counterparts
The following chart demonstrates which KPIs have been deprecated, as well as links to their new System Extensions replacements introduced in macOS Catalina.
Kernel Extensions that leverage one or more of the following KPIs that have System Extension equivalents will cause the previously mentioned alert.
System Extension Replacement
USB Vendor Specific IPC
How to Distinguish System Extensions from KEXTs
If you aren’t sure if a KEXT or a System Extension is running, there are a couple of Terminal commands that will help. In this section, we’re going to walk you through using the systemextensionsctl list command to get information about System Extensions on your Mac, and then how you can use a simple script to get information about Kernel Extensions.
If your company relies on an MDM (mobile device management) solution, the information that these methods give us regarding Team ID and bundle identifiers will be useful for bypassing prompts via Kernel Extension and System Extension profiles, which we’ll cover later.
Locating System Extensions
Let’s start with System Extensions. Most System Extensions can be found by accessing the /Library/SystemExtensions Directory. However, you can also use the systemextensionsctl list command in Terminal. This will give you a list of all System Extensions currently present on your Mac, along with additional information regarding Team IDs and bundle identifiers.
Here’s how you do it:
- Open Terminal
- Type in systemextensionsctl list
The command will return information about how many System Extensions were found. For a full example, here’s what this information would look like if a System Extension were found:
enabled active teamID bundleID (version) name [state]
* * 9PTGMPNXZ2 com.symantec.mes.systemextension
(10.0.0/10.0.0) Symantec System Extension
Again, take note of the Team ID and bundle identifier information. You can use this to create a System Extension configuration profile, as we’ll discuss in more depth later.
Locating Kernel Extensions
If you want to get information about Kernel Extensions on your Mac, you can use the following method.
- Open Terminal
- Copy and run this script in Terminal:
echo "Team ID,Bundle Identifier,KEXT Allowed,Developer Name,Flags"> ~/Desktop/kext.csv
sudo sqlite3 /var/db/SystemPolicyConfiguration/KextPolicy "SELECT * FROM kext_policy;" | sed 's/|/,/g' >> ~/Desktop/kext.csv
Once you run this script, a CSV file will open on your desktop including information on KEXTs that are currently installed on your Mac, including Team IDs and bundle identifiers. This information can be used to allow KEXTs responsible for those dialogue boxes we mentioned earlier.
What’s a System Extension Profile?
Essentially, System Extension profiles are configuration profiles that determine which System Extensions can use what System Extension frameworks. You can use these profiles to ensure that certain applications that use System Extensions will load on your users’ devices without prompting them to approve it.
To allow Kernel Extensions, IT just has to specify any Team IDs or bundle identifiers that correspond with the program team or bundle, that way the system can recognize if certain extensions should be executed or not. System Extensions, which perform the same tasks that were done by Kernel Extensions before Catalina, work the same way — so, they should also be allowed using a System Extension profile.
Ever since macOS High Sierra 10.13, User Approved Kernel Extension Loading (UAKEL) has been required in macOS. UAKEL is exactly what it sounds like: A user must approve Kernel Extensions that are needed before they can load in macOS. “Install Kernel Extension” dialogue boxes, like the legacy system extensions alerts we talked about earlier, are the prompts they use for approval.
However, since macOS 10.13.2, IT administrators have been able to use MDM solutions to allow Kernel Extensions to load without user consent. This capability requires enrollment in your MDM via Automated Device Enrollment or User Approved MDM enrollment (for a breakdown of these, see our guide to device enrollment).
If you meet this criterion, you can use those Team ID and bundle identifiers we found earlier to allow Kernel Extensions in macOS, allowing Kernel Extensions to install and load silently without needing user approval, doing away with prompts that disrupt the user experience.
As macOS continues to phase in System Extensions, the Kandji team is dedicated to sharing the latest developments with the IT community and making the most out of the opportunities it presents to push MDM forward. With powerful features like zero-touch deployment, one-click compliance, and offline remediation, Kandji has everything you need to enroll, configure, and secure your devices. It’s time to manage your Apple fleet like your business depends on it.