Live data from Hacker News

macOS extensions are moving away from the kernel

eclecticlight.co

71–80 of 149 posts

Re: macOS extensions are moving away from the kernel

#71

This article does a good job of explaining how kernel extensions worked under Intel and how they will work under M1, and the blessed replacement for kernel extensions by Apple under M1. What it's missing, and what I assume everyone's questions is: Are the capabilities of Apple's user-level APIs sufficient to replace most legitimate uses of kernel extensions?

> Are the capabilities of Apple's user-level APIs sufficient to replace most legitimate uses of kernel extensions? From what I remember reading from some macOS Application Firewall makers, no. (And that's ofcourse, intentional.) While it is true that poorly coded Kernel extensions can make an OS unstable, this is just another example of Apple taking away more control from its users and further crippling macOS to make…

> While it is true that poorly coded Kernel extensions can make an OS unstable, this is just another example of Apple taking away more control from its users and further crippling macOS to make it more like ios.

It isn't. They are making it (very) less likely for average simpleton users like myself to expose or fuck up their system.

And for the more elite hackers such as yourself who absolutely want to load third party kernel extensions, they require you to disable SIP. The knowledge and work it takes to do that is a very nice "I hereby declare I know what I'm doing and I alone bear the responsibility if things go wrong" entry barrier.

Re: macOS extensions are moving away from the kernel

#72
post #58

You can still find the official documents about how to make changes in the MacOS X kernel itself (dated 2004 or so...). It's really sad that we have come to this. The platform became more and more closed off in the name of security and no serious law or regulation is preventing that. And if at least it was bug free it would be worth it, maybe. But my kernel extensions are all for circumventing bugs or stuff that does…

You don’t need to use Karabiner for that: keyboard preferences has a modifier keys setting (per keyboard) that achieves this exact remapping with no kernel extensions.

Surprisingly not. You can't re-bind the FN key's function using normal settings.

On a 2019 mac pro, catalina, btw, looking at Settings > Keyboard > Modifier Keys...

Re: macOS extensions are moving away from the kernel

#73

Earlier quoted context omitted.

Well, I'm glad to see even the cynics can't find an evil motive here, and has to resort to just assuming stupidity. That, however, isn't easy to do, considering Apple has a rather impressive track record of creating products people enjoy and buy. And to jump two replies ahead: them trying to make it "easy" and "save" doesn't imply their users are idiots. Quite a few developers and scientists use Macs, and the lawyers…

Ironically, kexts allow me to have better backups in the first place. APFS won’t check for bit rot, nor does it allow to make snapshots. OpenZFS enables both, and works with a kext. I don’t know whether Apple will allow that use case in the future. I don’t like the way this is going.

You can definitely make snapshots on APFS. It also use checksums for filesystem integrity.

Re: macOS extensions are moving away from the kernel

#74
post #61

Earlier quoted context omitted.

"Pedantic"? If you just consider disallowing 3rd party modules to be a "microkernel" all while the kernel itself still loads most if not all (approved) drivers such as PCI bus, storage devices or filesystems in the same address space, then _all_ current major operating systems are "microkernels".

I was under the impression Apple intend to move those ( including their own ) outside as well with NetworkKit and DriverKit? Which is what pjmlp implies, once they are out, isn't it microkernel?

But they do not plan to move their own out, which is the point. That would require significant rearchitecture.

Re: macOS extensions are moving away from the kernel

#75
post #66

Very cool, more control lost.

I think the reason of security is a bit fishy too. I've never heard of wide-spread exploits from kernel extensions before.

Seems they just want to lock it down to squash developers making kernel level features for mac...

I'm sure someone will find a back door to allow extensions somehow, but we can't keep fighting forever :(

Re: macOS extensions are moving away from the kernel

#76
post #4
post #3

Earlier quoted context omitted.

The roadmap as presented by Apple at WWDC 2019 was that after an userspace replacement for a kernel subsystem gets presented, there is one year deprecation until it gets removed from the kernel on the following OS release. So there is one year to try out what might still be missing and give respective feedback. The long term roadmap is that macOS will eventually be much more microkernel like.

Cool! Very interesting development given how bad reputation microkernels had for a while. (I’m thinking of Linux vs Minix/Hurd.)

At the time of the Linux vs. Minix debate, on pretty much every performance measure that Linus said monolithic kernels were better at the microkernel QNX was totally wiping the floor with Linux.

Re: macOS extensions are moving away from the kernel

#77
post #67
post #55

Earlier quoted context omitted.

Non-extensible? Locked? "A kernel that only allows user-space third party drivers"? That this style doesn't have a nifty name isn't a good reason to weaken the established definition of microkernel just so it does.

It is kind of hard to implement a mikrokernel without any kind of drivers on the kernel. So, then it becomes a balancing act how many are allowed the priviledge to be part of the main act.

> It is kind of hard to implement a mikrokernel without any kind of drivers on the kernel.

Well, that is kinda the point of a microkernel (or at least one of the points).

Sure, you're not going to have a kernel whatsoever without say an CPU/MMU driver in the same address space. Maybe a driver for the timer.

But when you have graphics, sound, storage, USB controllers, filesystems, networking and most of a BSD kernel (providing all the syscalls) in the same address space, now that is not a microkernel by any definition of the word.

XNU is called an "hybrid" kernel in part because in the original design the BSD parts implementing most of the actual system could have been spun off as a separate process (similar to Windows NT's original design), which would have been an actual microkernel, but in practice they were just stuck together in the same process, making it a monolithic kernel in all but name (just like in Windows).

> So, then it becomes a balancing act how many are allowed the priviledge to be part of the main act.

Yes.

Re: macOS extensions are moving away from the kernel

#78
post #35
post #13

Earlier quoted context omitted.

I’m running a PreSonus StudioLive 16.4.2 (1st gen) and am stuck on 10.13.6 because I’m pretty sure they didn’t release drivers for 10.14+. It’s a FireWire 400 device. I absolutely love it but because of it, I’m probably never going to upgrade my studio mac. I do wonder if it’s a class a compliant device and works without drives (I think I read somewhere that it might work) but I legitimately use the software that com…

>and am stuck on 10.13.6 We have multiple Apple hardware based music systems 75% of which are deliberately still, not stuck, on 10.13.6.. We also have a few M1s. After decades of continual forced disconnects/'upgrades' of software/hardware compatibility we drew a line at 10.13.6 and have been very happy and have not missed a single so-called new feature, both from Mac OS or any DAW we use. We are, however, ready to m…

Upgrades suck, but at least MacOS leaves you alone if you choose not to update your OS. Windows shoves it down your throat...

Do you have a blog or anything with write ups about your equipment? Would be very interested in hearing about your silicon upgrades once you get there.

Re: macOS extensions are moving away from the kernel

#79

Earlier quoted context omitted.

I can’t comment on the internals of drivers etc as it’s not a domain I know much about, but I dabble with music production and can tell you that all my audio gear which requires drivers has been updated for Big Sur, which AFAIK is the new model. I’ve not noticed any change in performance at all, so I assume Apple have ensured the API covers the ground required for real time audio - it is one of their specialities as…

> it is one of their specialities as an OS/platform after all. Apple's been losing ground with creative-types across all industries and areas since their post-2000s peak: the major attitude-adjustment came with the reputational harm that came from the launch-and-downfall of the 2013 Mac Pro. As a wry zinger, I find it ironic that creative-types cannot express their creativity, and especially their individually by way…

Apples been doing that for yeaaars, especially with mobile devices (not that that's news to you)

Anecdote: I had an iPad pro I put in a drawer for a while. I had it synced to an apple account from my old job (used my corporate email for it).

When I took it out after I moved jobs, it became permanently locked with no recourse because I didn't have access to the email anymore.

And there was no way to factrory reset it, so it became as useful as a coaster. Really pushed me away from mobile apple devices...

Re: macOS extensions are moving away from the kernel

#80
post #59

Earlier quoted context omitted.

I am quite sure that we have been other this several times in HN. The fact that they're no longer going to allow loading of 3rd party kernel modules (a pure political decision) does not a make a microkernel (which is an architectural style). The kernel is still going to be big and monolithic (it contains the entire BSD kernel in the same address space!), and they're still going to be loading Apple-authorized kernel m…

> The kernel is still going to be big and monolithic (it contains the entire BSD kernel in the same address space!) macOS does not use “the” BSD kernel (it’s not even obvious what your assertion even means since there are many members of the BSD family, each with their own kernel - none of which macOS uses).

I'd assume they're talking about XNU, which ultimately derives from "the" original Berkeley distribution like all of the other BSDs.
Post reply on HN