Apple Says Kernel Extensions Won't Be Supported on Future Apple Silicon Macs | Hacker News Reader

Apple Says Kernel Extensions Won't Be Supported on Future Apple Silicon Macs

macrumors.com

41 pointsdmmalam15 comments

I've written a MacOS kernel extension. The API is a underdocumented mess. I understand why they would want to remove it, even it is just to eliminate the API burden, but, that means the last resort to add functionality that Apple hasn't deemed appropriate is closed off.

That's truly unfortunate.

Want to highlight the most upvoted comment on the article:

> At the end, their goal is that MacOS is just iPadOS with Terminal and Xcode.

Thats basically what their long term strategy is. It makes sense from a “normal user” point of view, dumbing down everything to meet the lowest common denominator.

The real question is, where are all the hardcore coders like us doing to end up? I hope there probably will be a suitable alternative when that time comes.

Linux and windows

Windows already moved its graphics drivers from kernel mode extensions to user mode processes years ago.

You can still create kernel extensions, there's just a process to get them approved. The requirements are a little more stringent than getting a signed driver, which makes sense as the permissions are higher.

Being most-upvoted doesn’t mean there is any truth to it.

The “principle of least privilege” is a cornerstone of developing secure software and if you view Apple’s new security features through this lens you can see what they are doing: sandboxing and translocation, moving input processing to isolated services, requiring permission before accessing privacy-sensitive APIs, preventing privilege escalation through inter-app debugging/tracing/code injection, etc. Code running in the kernel violates this concept and the only way to put up walls is to eject it to userland. And maybe having things like huge network file system implementations in the kernel wasn’t a great idea for system stability or security in the first place.

macOS will continue to be locked down but Apple has consistently built “escape hatches” for tinkerers: System Integrity Protection can be disabled; all Macs including the M1 can boot non-Apple kernels[0]; the kernel can be built from source[1]. The iPhone security research device program was in response to complaints about iOS being too opaque, and was a significant reversal in Apple’s position in locking down its crown jewel OS.

You can argue they don’t go far enough with those escape hatches---I sympathize, speaking as someone who publishes a kext that patches the kernel. I hate that holding certain kinds of entitlements makes a process much more difficult to debug. And they can always change their minds later.

Orthogonal to least privilege is vetting that code is trusted, which is the root of fears over an App Store-only software distribution model, but most changes regarding code signatures can similarly be viewed through the lens of malware protections, given a sharp increase in the number of attacks targeting macOS.

0: https://twitter.com/XenoKovah/status/1339914714055368704

1: https://kernelshaman.blogspot.com/2021/02/building-xnu-for-m...

While I understand the argument for removing kernel extensions, I don't think I can agree with it. It should be possible to run your own software at the kernel privilege level. There are usecases where that's essential, and for the long term it ensures that the whole system does not become overly closed.

> There are usecases where that's essential

Which ones do you have in mind?

There are operating systems specifically made to allow for tinkering with the internals. Mac OS, and Windows are not among these. Over time, each has allowed the user to control fewer aspects of the system. And there's nothing the users can do to stop it. What are they going to do, switch to Linux or BSD? Hah. Anybody who hasn't bailed already is stuck forever with their platform of choice, I would say.

Why is anyone stuck?

If you need to run code in the kernel, you’re obviously competent to use Linux or BSD when needed.

Proprietary systems imply vendor lock-in. The more one becomes dependent on a locked down system, the harder it becomes to migrate your data out of it.

> Proprietary systems imply vendor lock-in.

It seems like you are talking about proprietary data formats used by end-user applications.

That doesn’t have anything to do with choice of platform.

It also doesn’t have anything to do with writing kernel extensions.

So... is Apple going to develop drivers for all possible peripherals?

For USB you have libusb I guess (not sure if that covers all us cases), but Thunderbolt is a full-on PCIe bus isn't it?

They have been developing DriverKit, an API for third parties to develop device drivers in userland.

Reply on news.ycombinator.com