> Kernel programming interfaces (KPIs) will be deprecated as alternatives become available, and future OS releases will no longer load kernel extensions that use deprecated KPIs by default.
This is the key part, as presented during the WWDC 2019 talks, the long term roadmap is to make macOS into a proper mikro-kernel OS.
Nothing about Xnu leads me to believe they are pursuing a bona fide micro-kernel architecture. This doesn’t really indicate anything in that direction either. They’re just doing the typical Apple thing of enforcing a “one proprietary port, one licensed plug” policy.
We had a very serious performance issue resulting in crashes across our fleet of macs that was ultimately traced back to an endpoint security solution that was patching the kernel and doing dumb stuff.
These changes from Apple have forced this vendor to completely rewrite their product the right way.
I saw a rewrite of some functionality from a vendor (rhymes with mcafsee) as well. They decided to start running lsof to find open files. This can be excruciatingly slow and cpu intensive on macOS. It was running it near constantly effectively turning machines into beach ball render farms.
I suppose avoiding kernel panics is an improvement but let’s be real: these enterprise vendors have always made shit software and rarely keep up with OS releases or updates. They’re not about to change any time soon.
Indeed, but they are what causes OS vendor to actually do something about it.
Android now is requiring hardware memory tagging on ARM, Fortify by default, and Treble requires out-of-process for new drivers exactly because of the same kind of issues.
"MacOS 10.15 Catalina will be the last release to fully support Kernel Extensions without compromises." Specifically, for the capabilities supported by System Extensions and the device families supported by DriverKit, using a Kernel Extension to do that same job is now deprecated and a future release of macOS will not load Kernel Extensions of these kinds. In future releases, we will add more kinds of System Extensions and more device families to DriverKit.
In turn, Kernel Extensions of those kinds will also be deprecated."
Banning third-party developers from loading modules into kernel-space does not a microkernel make.
Apple-approved developers are still going to be loading whatever crap they want into kernel space, incl AMD or nVidia graphics drivers and the lot. It's not like they can convert XNU into an actual microkernel in less than a decade or two.
This just means that if you're not on the Apple-whitelist then macOS becomes a yet even more close platform for you. Wanted to developed a driver for a PCIe network card? Sorry, no can do!
GPUs are kind of interesting, because the kernel space part of a GPU driver is managing the MMUs, and a lot of microkernels see MMU management (even of devices) as still one of their core roles. It's basically a really legacy IOMMU inside most GPUs. Split off a user space process to kick off command list execution and respond to interrupts (most of the rest of the kernel driver these days), and I can totally see a microkernel with GPU drivers in it still being ideologically pure.
If they were going to make a microkernel they would have done it when they made mach, not after 20 years of writing kernel GPU drivers, network drivers, etc.
This is the key part, as presented during the WWDC 2019 talks, the long term roadmap is to make macOS into a proper mikro-kernel OS.
This is just the start.