Get to know more about kernel extensions here
Learn how to extend system capabilities using Mac kernel extensions
Get fresh insights, pro tips, and thought starters–only the best of posts for you.
Eugene Raynor
Jul 22, 2021
17 min read
Apple has always strived to achieve the best in safety and security for their devices. So much so that when we’re talking about desktops, Macs are the go-to choice for businesses that require reliability and security. It is no wonder then that Apple decided to make the move from the legacy kernel extensions to the safer and more secure Mac system extensions. But what was the reason behind this move? Why were KEXTs considered as such a big security risk? And what exactly, are system extensions? Here is everything you need to know about Apple’s move away from the legacy KEXTs, and the coming of Mac system extensions.
Mac system extensions are a category of software or specific application bundles, used to extend the functionality of a macOS device. System extensions work very similar to kernel extensions. But the difference is – unlike KEXTs (which runs in the kernel space), system extensions run in the user space outside the kernel, like other apps and software. To get to know more about Mac system extensions, I think a basic overview of the legacy KEXTs and how it works, is necessary. So here goes.
Mac system extensions are the modern-day replacements that Apple has suggested in place of kernel extensions for macOS devices. With system extensions, Apple provides new frameworks for developers to perform tasks (with KEXTs, developers were limited with just one framework). This includes eliminating restrictions on dynamic memory allocation, synchronization, and latency, the ability to use any framework in the macOS SDK, and the utilization of any programming language, including Swift (kernel extensions were limited to C and C++).
Now, in terms of function, macOS system extensions work very similarly to kernel extensions. So much that if you’re the end-user, you probably won’t notice the difference. However, unlike KEXTs, Mac system extensions don’t make use of the kernel space. That is, they are not loaded directly into the macOS kernel. Instead, they run in the user space, as other apps and software do, and are controlled and kept at bay by your Mac’s security rules.
What does this mean? If a system extension crashes, the rest of the macOS system and its apps remain unaffected and keep functioning. This factor makes system extensions the more reliable and secure option when compared to KEXTs.
The announcement at the Worldwide Developers Conference (WWDC) 2019, on the deprecation of kernel extensions and the replacement with Mac system extensions, was a sign that Apple had realized the potential risks posed by kernel extensions (KEXTs), and shifted their focus to better tech. Likewise, this is a call for the rest of the IT world to follow suit.
Mac kernel extensions | Mac system extensions |
Software is loaded directly into the macOS kernel (kernel space) | Software is not loaded into the kernel space. Instead, utilizes the user space |
Kernel extensions are not bound by macOS security policies | Like any other software, system extensions are bound by macOS security policies |
In cases of vulnerabilities, takes down the entire macOS system | In case of vulnerabilities, does not bring down the entire system |
Restrictions on dynamic memory allocation, synchronization, latency | No such restrictions |
KEXTs cannot use system frameworks | System extensions can use any framework in the macOS SDK |
Kernel extensions only support C/C++ languages | System extensions support all languages, including Swift |
Okay, so let’s get to the big question. If system extensions function outside the kernel space, then how could they achieve functionalities on par with kernel extensions? Especially when system extensions are bound by Mac’s software rules and kernel extensions are not?
Easy. It’s because these system extensions are granted special privileges, with the help of frameworks (or special APIs) that provide apps with direct access to their associated hardware and internal kernel interfaces (without requiring them to load directly to the kernel).
Currently, three frameworks are used by Mac system extensions to replace the functions offered by legacy KEXTs.
The DriverKit framework defines the fundamental behaviour for device drivers on your Mac. This framework determines your driver’s basic structure, and provides support for handling events and allocating memory. You can use the DriverKit framework to create drivers for USB, serial, network interface, and human interface devices and install them on your Mac. (Due to their close relationship to the macOS hardware, driver extensions must still be written in C or C++ and must make use of the DriverKit framework.)
With the Network Extension framework, you can customize and extend core networking functionalities, including – changing the system’s Wi-Fi configurations, creating and managing VPN configurations, implementing an on-device content filter, creating and managing system-wide DNS configurations, and more.
The Endpoint Security framework is an API for monitoring system events for potentially malicious activity and even blocking system events to better conform with macOS security policies. Basically, it replaces legacy KEXTs that monitor security events with KAUTH interfaces. Endpoint Security Frameworks (and APIs) are utilized by security apps such as endpoint detection and response, anti-virus software, and data loss prevention apps.
Although macOS system extensions provide functionalities similar to kernel extensions (that too in a more reliable and secure manner), for now, a complete transition to system extensions isn’t possible. This is because some kernel extensions still use KPIs that are not supported by the available three system extension frameworks. This includes KPIs for virtualization software such as VirtualBox and Parallels (which could enable you to run platforms such as Windows within a Mac). As a result, the kernel extensions for such software still operate outside the possible system extension frameworks. And in such cases, IT must continue to use KEXTs until Apple offers a suitable system extension replacement.
Here are a couple of things that users should know before approving system and kernel extensions on their Macs.
We’ve provided detailed explanations in the upcoming sections on how to deal with each of these cases.
The following are the system extension replacements for their corresponding deprecated or unsupported Kernel Programming Interfaces (KPIs).
Unsupported: The KPI is no longer supported. Any kernel extension using an unsupported KPI will not load.
Deprecated: The KPI is available but will become unsupported in the future.
Loading one of the following KPIs with a system extension replacement will trigger the ‘Legacy System Extension’ dialogue box.
KPI | System extension replacement | Unsupported after | Deprecated after |
KAUTH | EndpointSecurity | macOS Big Sur 11.0 | macOS Catalina 10.15 |
Network filter | NetworkExtension | macOS Big Sur 11.0 | macOS Catalina 10.15 |
Socket | NetworkExtension | – | macOS Catalina 10.15 |
IOHID family | HIDDriverKit | macOS Big Sur 11.0 | macOS Catalina 10.15 |
IOUSB family | USBDriverKit | macOS Big Sur 11.0 | OS X El Captain 10.11 |
USB networking | USBDriverKit NetworkingDriverKit |
macOS Big Sur 11.0 | macOS Catalina 10.15 |
USB serial | USBDriverKit SerialDriverKit USBSerialDriverKit |
macOS Big Sur 11.0 | macOS Catalina 10.15 |
USB vendor-specific IPC | USBDriverKit IOUSBHost DriverKit |
macOS Big Sur 11.0 | macOS Catalina 10.15 |
PCI networking | PCIDriverKit NetworkingDriverKit |
macOS Big Sur 11.0 | macOS Catalina 10.15 |
Now, if you need to identify the kernel or system extensions on your Mac and find its Team ID and Bundle ID, you can use the following commands or scripts and input them into the terminal.
In case of system extensions, most of them can be found by accessing the /Library/SystemExtensions folder. However, you can also use the terminal command –
1 |
systemextensionsctl list |
– to obtain the information on all system extensions on your Mac. Just input the above-mentioned command in the terminal and press ‘Enter’. The number of system extensions, along with the software details of each, including the Team ID and Bundle ID will be displayed.
To identify kernel extensions on your Mac, open the terminal and enter the following command –
1 2 |
sudo sqlite3 /var/db/SystemPolicyConfiguration/KextPolicy SELECT * FROM kext_policy; |
A list containing the Team ID, Bundle ID, and display name of the developer of each kernel extension will be displayed (The first item in the list will be the Team ID, followed by Bundle ID).
Since the introduction of macOS High Sierra 10.13, end-user approval is necessary before loading kernel extensions onto their Macs.
As an end-user, you can easily approve kernel extensions by following the below-mentioned steps.
With the help of Hexnode UEM (on devices running macOS High Sierra 10.13.2 and higher) IT can specify a whitelist of system and kernel extensions that can be automatically loaded on the specified Macs, eliminating the need for user-approval prompts that ultimately disrupt the overall user experience.
There are three ways to deploy kernel extensions using Hexnode.
Specify the Team ID of the signed kernel extensions. This will automatically approve all kernel extensions that possess the whitelisted Team IDs, regardless of their bundle IDs.
Specify the Team ID and Bundle ID of the signed kernel extensions. This method will approve only the specified kernel extensions with the correct Team ID and Bundle ID to load on a Mac.
For the case of unsigned kernel extensions, specify only the Bundle ID and leave the Team ID blank.
There are four ways to deploy system extensions using Hexnode.
Specify the Team ID of the signed system extensions. This will automatically approve all extensions that possess the whitelisted Team IDs, regardless of their bundle IDs.
Specify the Team ID and Bundle ID of the signed system extensions. This method will approve only the specified extensions with the correct Team ID and Bundle ID to load on a Mac.
For the case of unsigned system extensions, specify only the Bundle ID and leave the Team ID blank.
You can also approve system extensions on your Mac based on the system extension types. Here, any system extension that belongs to the allowed types (Endpoint Security Extension, Driver Extension, and Network Extension,) and possesses a whitelisted Team ID, will be allowed to load on a Mac.
For additional information on configuring system extensions and KEXTs using UEM, make sure to read Hexnode’s help documentation on configuring system extensions and kernel extensions for macOS devices.
With the introduction of macOS Catalina, system extensions have begun to steadily replace legacy kernel extensions for almost every purpose. However, there still exists some functionalities that are not covered by the three system extension frameworks (eg: KEXTs for virtualization software). In such cases, kernel extensions are still required for the proper functioning of the software.
That being said, it is crucial to point out that system extensions are a part of Apple’s commitment to gradually eliminate the use of kernel extensions and create a more reliable and secure setting for Macs. Hence, wherever possible, you must ensure to use system extensions in place of KEXTs. With the help of a UEM solution like Hexnode, IT can easily streamline the deployment of system extensions and KEXTs to their corporate Macs, and ensure a safe and secure environment for their business.
Get a free trial for Hexnode UEM for 14 days and get the most out of our Mac management capabilities
TRY IT OUT
Share your thoughts