With the release of 10.15 Apple announced the deprecation of kernel extensions in favour of user space based drivers. I remember when the announcement was made I wasn’t expecting it to kick in maybe until the following release (macOS 10.17) but it appears that support maybe completely removed in macOS 10.16. With the release of 10.15.4 a message is now displayed to the end user when they’re reliant upon a third party kernel extension (link).

The reason for this? It all comes down ti security – anyone who has been following the updates that Apple put out on a regular basis they also include a document where it outlines all the security bugs that have been fixed (link). If you have a look through there are at least 14 instances of kernel vulnerabilities relating to either the kernel itself or an kernel extension. If something goes wrong for any code running in kernel space then it opens up the whole system – even with fuzzing techniques etc. it is difficult to debug because of the process of crashing, rebooting, recompiling, checking code dumps etc. which s time consuming and even with automated tools it can give hints about where there might be an issue but it doesn’t pin point exactly resulting in still many hours of work. The situation is made worse if you’re dependent upon third parties to maintain their code as well then timing it so that you can merge it with your update then testing it then provide feedback up to the third party to then receive an notified binaries back again to then retest.

I don’t think it will ever be possible to have a 100% secure kernel or a system as a whole but what one can do is decrease the surface attack area by taking steps such as Address Space Layout Randomization (ASLR) but there are limits which s why there is a focus on deprecating kernel extensions support for third parties in favour of moving driver developers over to using the user land DriverKit API so that misbehaving extensions don’t bring down the whole system and more importantly that a security vulnerability in an user land extension doesn’t pose a giant security risk for the rest fo the system.

It appears that Apple is already starting to make it use the framework:

A term known as ‘Dog fooding’ is a process where by developers will make use of their own code in the early stages so that the framework develops to meet real world needs rather than a situation of trying to develop a framework in an abstract way but finding that in the real world it doesn’t meet developers needs. This is an important part of making the framework more robust – moving drivers over to the framework (because that is what a lot of developers will be doing m in terms of moving their existing code base to a new framework – they aren’t going to throw away thousands of man hours of battle hardened code if they can avoid it) and as they see how certain drives behave they can make adjustments to the framework so that by the time it is ready for third party developers it will be ready to be used barring corner cases that’ll need to be addressed on a case by case basis.

Although this is speculation on my part I think that over the long term that part of the move to ARM for Mac will involve pushing the kernel in either a micro-kernel or at least a monolithic kernel but trying to push as much out of kernel space as possible. Although there is a performance hit in terms of context switching on x86, on ARM the cost is a lot lower and if Apple takes advantage of ARM ISA extensions then the performance penalty will be almost nothing. By moving the drivers out of the kernel it’ll also allow them to make radical changes to the kernel without having to be concerned about driver compatibility – there has been much made about inefficiencies within macOS kernel (XNU) with some of them the result of architectural decisions (valuing low latency over throughput for example) and some of them being the result of decisions made based on hardware limitations that are now becoming an impediment (see the slow removal of the giant lock and the emergence of multi-core CPUs becoming mainstream in recent years).

It appears that they’re most likely going to start pushing USB devices into user space first but then eventually work their way into areas such as the graphics subsystem where all but the most essential code sits inside the kernel which is shared amongst all the vendors which will hopefully mean maybe a return of support by nVidia since it would mean support for nVidia GPU’s wouldn’t be dependent on a kernel extension. I could also imagine seeing Apple pull the all the file system drivers out of the kernel thus leaving APFS the only one loaded in the kernel. This would all make sense given that for years they’ve been breaking down their kernel extensions into smaller components. The best example of that would be the video card drivers where they’ve been broken down into a shared common kernel extension, a hardware abstraction library, a services extension etc. where as before it was all dumped into a single file and left it at that.

I guess in June 2020 when there is WWDC we’ll get to see where Apple is going to be taking macOS (and their other operating systems) in the future.