macOS extensions are moving away from the kernel • Hacker News Board

Re: macOS extensions are moving away from the kernel

#81

Post by tzs » Wed, Jul 07, 2021, 2:09 PM UTC

zvrba wrote: post #52

als0 wrote: post #25

Earlier quoted context omitted.

Rings 1 and 2 don't even exist on AMD64/x86-64.

Yes they do, but segmentation is practically non-existent and page tables distinguish only between rings 0 and rings 1-3. So no, they aren't very useful, but they do exist and, AFAIK, they're still checked in "far" control transfers.

It's too bad they have been made useless. I'm not fully sure about this, but I think that if you could have two rings for user code so that applications that want to run untrusted code in a sandbox could run the main application in ring 2 and the sandboxed code in ring 3, you could make the application safe from Spectre attacks from the sandboxed code without giving up performance.

Re: macOS extensions are moving away from the kernel

#82

Post by kmeisthax » Wed, Jul 07, 2021, 2:16 PM UTC

AshamedCaptain wrote: post #19

nemothekid wrote: post #2

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?

The entire "ring 1" thing is highly likely false. It's been decades since I last saw anyone using the x86 ring levels and I seriously doubt XNU is using them. In any case, extensions run in the same address space as the rest of the kernel making any such "rings" pointless.

The funny thing is that the M1 has an undocumented but totally used feature called Guarded Execution[0] that lets you separate parts of the kernel (or hypervisor, if you're in EL2) from one another. Basically, on the M1 each Exception Level now has a regular and a guarded sublevel, with their own page table permissions, and special instructions to enter or exit the guarded execution within the same EL.

macOS on the M1 uses this to prohibit most kernel code from touching pagetables. You have to do that from within the guarded sublevel, which kernel extensions can only call into.

This is more or less the original intent of x86 rings: to separate an OS kernel out into parts with different permissions and levels of isolation.

[0] https://blog.svenpeter.dev/posts/m1_sprr_gxf/

Re: macOS extensions are moving away from the kernel

#83

Post by jen20 » Wed, Jul 07, 2021, 2:17 PM UTC

spicybright wrote: post #72

jen20 wrote: post #58

Earlier quoted context omitted.

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...

Same Mac, Big Sur, the Fn key binding is there.

This article [1] suggests that it was the case at least in Catalina given the screenshots - but I don't have it easily available to test.

[1]: https://howchoo.com/mac/mac-remap-fn-to-ctrl

Re: macOS extensions are moving away from the kernel

#84

Post by TheRealDunkirk » Wed, Jul 07, 2021, 2:21 PM UTC

the_other wrote: post #7

I've love to hear what this means for realtime multi-channel audio applications. Would someone close to this give us a summary, or recommend some resources for the only-barely-knowledgeable?

I just got another warning this morning that my kernel extension for Dante Virtual Sound Card by Audinate is deprecated. I would hope that this would get some love in the new paradigm, otherwise it's basically goodbye to doing any live audio capture on an M1. I just worry about the latency. It's hard enough to keep Logic from losing sync already, even with all the buffers maxxed out, recording to an NVMe drive, from a gigabit network, with a segregated VLAN. Yes, I'm doing 48 channels, which is a lot, but the audio production "community" doesn't need ANY more latency introduced into this pipeline.

Re: macOS extensions are moving away from the kernel

#85

Post by zibzab » Wed, Jul 07, 2021, 2:45 PM UTC

roblabla wrote: post #24

creshal wrote: post #9

Earlier quoted context omitted.

Some of the userspace drivers are even shared between OSX and Linux, via FUSE.

Another example would be userspace network drivers that directly talk to the network card. Those tend to be much more performant than using the kernel driver due to avoiding the need to context switch from userspace to kernelspace.

Is that really true in pratice (excluding unikernels, of course)?

Re: macOS extensions are moving away from the kernel

#86

Post by 1123581321 » Wed, Jul 07, 2021, 3:17 PM UTC

spicybright wrote: post #75

oauea wrote: 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 :(

My understanding is that narrowly targeted exploits are more the concern.

Re: macOS extensions are moving away from the kernel

#87

Post by smoldesu » Wed, Jul 07, 2021, 3:27 PM UTC

nemothekid wrote: post #2

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?

I would have trusted literally anyone else to do a good job at this. Apple's in the business of brokering power though, I see no reason why they'd be motivated to make those APIs as rich as kexts.

Re: macOS extensions are moving away from the kernel

#88

Post by rubyist5eva » Wed, Jul 07, 2021, 3:33 PM UTC

deregulateMed wrote: post #38

nemothekid wrote: post #2

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?

"blessed" replacement Why did you use the word Blessed? I'm curious what made your brain choose that word instead of something neutral. Reminds me of "Walled garden" marketing speak instead of "Walled Prison". Edit- is there some sensitive nerve I hit?

It's a back-handed use of the word as a criticism. Apple is "god" and they "bless" things that are approved by them-and-only-them to be "good".

Re: macOS extensions are moving away from the kernel

#89

Post by vimacs2 » Wed, Jul 07, 2021, 3:58 PM UTC

pjmlp wrote: post #41

tinus_hn wrote: post #26

Earlier quoted context omitted.

It’s not about pedantry; whatever rules you define for a micro kernel it shouldn’t be rules for thee but not for me

From all purposes from a third party driver writer persona, the only path forward are user space drivers. What you call a kernel like that?

A restrictive monolith kernel?

Re: macOS extensions are moving away from the kernel

#90

Post by Hackbraten » Wed, Jul 07, 2021, 4:17 PM UTC

yehaaa wrote: post #73

Hackbraten wrote: post #49

Earlier quoted context omitted.

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.

> You can definitely make snapshots on APFS.

Apple can. I can’t. Making APFS snapshots requires special entitlements, which they’re not going to give me.

> It also use checksums for filesystem integrity.

It doesn’t check integrity of the actual data though. But I care about my data.