Kernel extensions have long been one of the most powerful and dangerous features of macOS. They enable Apple and third-party developers to support the rich range of hardware available both within and connected to Macs, to add new features such as software firewalls and security protection, and to modify the behaviour of macOS by rerouting sound output to apps, and so on. With those comes the price that kernel extensions can readily cause the kernel to panic, can conflict with one another and with macOS, and most of all are a security nightmare. For those who develop malicious software, they’re the next best thing to installing their own malicious kernel.
For some years now, Apple has been encouraging third-party developers to move away from kernel extensions to equivalents which run at a user level rather than in Ring 1. However, it has only been in the last year or so that Apple has provided sufficient support for this to be feasible. Coupled with the fact that M1 Macs have to be run at a reduced level of security to be able to load third-party kernel extensions, almost all software and hardware which used to rely on kernel extensions should now be switching to Apple’s new alternatives such as system extensions. This article explains the differences these make to the user.
A good, detailed look at what Apple is doing with kernel extensions in macOS.
Justg another way for Apple to lock down MacOS. This is going to be a great hindrance to the Hackintosh community
The123king,
Yes it is another way for apple to lock down macos. I actually think hackintosh users could be in a better position to bypass the restrictions. Of course, with the migration to ARM, macos on x86 may not be an option too much longer. That’s got to be bad news for hackintosh users.
Windows has something similar in the 64-bit versions in the form of PatchGuard. I don’t see why installing kernel drivers is some sort of a universal right that should be given to users. The 32-bit versions of Windows did allow unrestricted kernel patching, and they were so susceptible to rootkits that even paid software started using rootkits techniques. XCP, MicroVault, and StarForce come to mind. Even antiviruses did extensive kernel patching so they could secure the sensitive parts of the kernel before malware did, in a weird game of capture-the-flag.
The reason XP users had pleasant memories of the OS during XP’s later years was because 64-bit versions of Vista disallowed patching, and all this better-behaved software also reached XP users. During its first years, XP (and Windows 2000 for that matter) were unstable POSes because of all the kernel patching going on even by paid software, and yes, users complained about it.
So, no, you can’t trust the user to not install kernel extensions when the software those users have paid for demands it. You know they will cave in and install the kernel extensions and then complain to the OS vendor about how the OS is unstable. The kernel’s functionality is defined by the OS vendor. Exclusively.
kurkosdr,
When corporations hold they keys, our platforms become more closed. Why shouldn’t owners should have the right to mod their own property as they see fit?
There’s no denying the 32bit versions were a security mess, but we need to consider the fact that microsoft never gave owners adequate cryptographic security controls (similar to the CA management you’d find in a browser). With 64bit versions of windows they gave themselves stronger security, but MS decided that it would not be providing the FOSS community with the tools necessary to run our drivers securely on our own machines. The only option was to go the corporate route (not financially viable for many independent devs working on their own time) or disable the validation using bootloader options, which brought 64bit windows back down to 32bit levels of insecurity. It’s the logical equivalent of disabling SSL validation on all certificates because the owner would like to use his own self-signed certificate. We can all agree this is a terrible idea, but that’s the contrived choice that microsoft left the FOSS community with.
This was all happening when microsoft was calling open source projects a cancer, so this may have played a role in why microsoft wouldn’t work with us to improve the situation. I think in retrospect microsoft’s anti-FOSS attitude was a major blunder that resulted in brain drain. Developers including myself migrated to linux in search of a more welcoming platform. This would cost microsoft dearly, especially in enterprise/server environments. I’ve gotten off topic though, haha.
This is not about signed vs unsigned drivers. Although Vista did (finally!) introduce a dialog box to warning the user when apps tried to install unsigned drivers, it’s irrelevant. This is about kernel patching. Nobody has to give you the option to patch the kernel in a supported way, just like no car manufacturer has to give you the option to mess with the ECU settings or whatever. You have the right to modify your own property as you see fit (most of the times), but if it doesn’t work or if it breaks the product, then you have what is commonly known as a “you” problem. Keep in mind I said “modify” not “repair”, which is a right.
Thank god kernel patching is dead on Windows (the 64-bit editions). I always hated the idea of running a kernel that is half Microsoft code and half AV vendor code or third-party copy protection code or malware or whatever. Much like USB autorun (or even optical disc autorun without confirmation), it always struck me as one of those “what the hell were they thinking” ideas that I was glad to see go away.
kurkosdr,
You could write a driver to patch arbitrary kernel memory, but ideally the kernel should be flexible enough that we should never have to do that and it should be discouraged. There are cool use cases though. I think some commercial distros can upgrade the kernel on the fly without rebooting. Personally I’d just reboot the machine though, haha.
Of course, I have no problem taking responsibility for the mods on my own system.
Unfortunately not all tech companies give consumers the tools and information needed for repairs either. Insert one of Louis Rossman’s rants here, haha. It’s been a long road for right to repair advocates.
Yeah, cool use cases like XCP and other malware. If some OS vendor wants to upgrade the kernel on the fly without rebooting, they can introduce some specific functionality for that. No need to allow arbitrary patching of the kernel.
My point is that you have the right to modify your property in a strict legal sense, but the manufacturer (or software vendor) doesn’t have to make this easy for you if they think that making this “deep” modification easy will lead to rootkit malware. I don’t exactly like the idea that everything should be easily modifiable down to the core (kernel), even if this results in problematic situations like Windows XP. At some point, you are buying a product with certain specs and behaviour and anything beyond that is a “you” problem.
Again, keep in mind I said “modify”, not “repair”, which should be made easy and documented.
To put it in plain words, I should have the right to repair my car without going through the official dealership (and the customary shakedown happening in those places for out-of-warranty customers), but if I want to rice-up the ECU to race Vin Diesel, then they don’t have to make this easy (or documented) for me. In fact, some brands heavily lockdown their ECUs. I can install a new radio and other “non-core” stuff, but at some point, wanting to modify the “core” (kernel) parts in fundamental ways doesn’t have to be easy. Because then everyone will do it and they will complain to the manufacturer when they break their stuff, and they will try to revert the changes and claim a warranty fix.
I mean, suppose some third-party software patches the Windows kernel to prevent suspend, and the computer is a Surface laptop, and it overheats inside a laptop bag and dies or suffers heavy battery damage. Does Microsoft have to provide a warranty on this? Does Microsoft had to provide support to all those customers getting issues from Windows XP rootkits or even paid software like XCP? At some point, the OS vendor has to protect themselves (and their reputation) and make deep modifications hard on purpose, so only people who know what they are getting themselves into can do it. “Normal” customers have to be supportable, and this can be done by keeping the core parts intact for those customers.
If you don’t know how to spin your own Windows ISO, you have no business patching the Windows kernel, plain and simple. Same for MacOS.
kurkosdr,
Windows (NT) uses a microkernel that was supposed not to need any kernel based drivers. In theory HAL was there to allow portable additions to kernel. In practice this has not worked well.
https://en.wikipedia.org/wiki/Architecture_of_Windows_NT#Hardware_abstraction_layer
Especially in Windows Vista they added tighter kernel integration, which caused lots of blue screens (thanks to broken nvidia and sound blaster implementations). And they also let anti-virus software to patch the kernel as well.
I think Windows kernel is still a hybrid model. The anti-virus thing might have been closed, but there was a full page ad criticizing patch guard from Symantec (their software was patching the kernel, and frankly usually made the system less secure).
But they were proven really secure in Xbox One — it was not hacked in the last gen. That could be why, they are migrating all those tools, including TPM 2.0 requirement to Windows 11.
(Mac OS also used a microkernel – Mach – but I have less information about that).
kurkosdr,
Sarcasm detected. Obviously ring 0 can be used for good or bad, same with root access, bios access, dual booting, direct filessytem access, pci access, raw network access, usb access and so on. Should these be secure by default, absolutely! But at the same time there are times we do need deeper access into the system. Owners should be able to make the choice for themselves. Their authority on their own machines shouldn’t be taken away by corporations.
Saying we have legal rights is great, but when corporations are actively interfering with our ability to practice them, that’s a real problem. The thing is, if we are unable or unwilling to meaningfully protect our rights, they will be lost. It’s also worth nothing that they always use the same excuse: “we’re doing it to protect you”, but it often entails much exaggeration and it doesn’t justify taking away owner rights.
Great, as long as owners have the choice then I’m in.
Alfman and kurkosdr,
So my question is what’s the solution to both sides? I’m not seeking to be facetious. I think both sides have validity. HOW do we ensure that users retain full rights to their system while allowing companies to protect themselves (legally and public perception wise)?
I agree wholeheartedly with right to repair since I like to be able to do some car repairs and save $$ for my family. Yet, if the company documents the full process, but requires me to (1) buy a ton of specialty tools (quite possibly a large expense) and/or (2) spend hours to do basic repairs b/c of the complexity, seems anti-right-to-repair and anti-DIYer. To give an example: my SUV’s headlights are SUPER simple to replace, but a previous car’s headlights required turning the wheels all the way to one side & were STILL hard to reach to reinstall. Repair shops wanted $60+ PER headlight b/c of that. That doesn’t seem very much in the “right to repair” category, even if it was documented somewhere. And yes, both vehicles were the same make, just 5 years apart in age (the SUV being older, which I still have b/c of the ease to repair & reliability).
cacheline,
For starters, personally I don’t pretend that root jailbreaking/root access/etc is for everyone, so it doesn’t necessarily need to be “easy”, but it just needs to be documented & possible for all owners seeking it. For security it must not be remotely triggerable obviously. It could be an option in the bios. Given that it wouldn’t need to change very often, it could be a physical dip switch, etc. Mandating both physical access and the owner’s password would be reasonable IMHO.
Another possibility is that the owner could be prompted for an unlock key, which needs to be obtained from the manufacturer. I’m less a fan of this approach because it leaves manufactures free to hold customer device’s hostage, but with adequate legal protections for consumers it could work.
I see your point, although we need to tread carefully because we don’t want to give any ammunition to people who say “your right to repair is making my device thicker/heavier/etc”. I’m ok with devices that require a certain degree of skill to repair. Not everyone is going to be able to repair everything themselves. But it’s not ok for manufacturers to block repairs such that even a skilled repair shop wouldn’t be able to do it (ie because they’ve intentionally withheld information and designed the system to block repairs).
I can definitely understand that we don’t want to go back to brick style phones. Yet, on the other hand, I used to build & upgrade desktops periodically for myself and friends/family. I also like the idea of being able to add RAM, hard drives, CMOS batteries, and other simpler items in a laptop. So, I’m less a fan of the soldered nature of a modern MBP, even though I like and use macOS.
It definitely seems like a big question to solve of the fine line b/w too locked down & too easy to break & make the manufacturer look incompetent.
cacheline,
I’m in full agreement with you, but I just felt the need to play devil’s advocate because it’s an argument that has been used against right to repair and we should have an answer for it.
The vast majority of professional mac users would likely prefer replaceable components given the choice, and of course apple knows this. However they also know that their users are very brand loyal and will still buy apple computers even though can’t be repaired/upgraded like in years past.
Presumably Apple have already run the numbers and have concluded that the additional revenue from planned product obsolescence (due to intentionally difficult repairs and/or inability for users to upgrade) is worth more to apple than the customers who threaten to leave in protest of said inability to repair/upgrade.
It shouldn’t matter if it’s a phone, dishwasher, tractor, whatever, I think that for the sake of our planet we need to stop business practices that intentionally design products to be difficult to fix/upgrade just to drive sales. Unfortunately an awful lot of companies are guilty, but how do we codify a regulatory framework to combat this without getting into nitty gritty details?