Darling: [newlkm] Upgrade to xnu-3789.41.3

[LubosD]

Upgrade to xnu-3789.41.3 to get Mach vouchers support + Mach port guard APIs.

[LubosD]

TODO: these functions should be fully implemented and use into Linux's schedule() & wake_up_*():

• [x] thread_block
• [x] thread_go
• [x] timer_call_enter_with_leeway, timer_call_setup (+ call this from thread creation), timer_call_cancel, thread_timer_expire
• [x] thread_mark_wait_locked?

evpsetfd.c will need an implementation of these functions for kqueue & Mach ports to work:

• knote
• klist_init?

[TheBrokenRail]

Will this add host_statistics, it looks like it is needed for top to work.

[LubosD]

@TheBrokenRail No, this is completely unrelated. It should fix #368, however.

[ErikEklund]

Just curious - 3789.41.3 is 3 years old at this point, latest xnu kernel is 4903.241.1 from what I can tell. Would upgrading to later versions be simpler once the Linux <-> xnu "glue" is in place? Would there be any useful benefit in using later versions? Or would it just be a massive amount of work for little benefit?

Maybe another task to add to #584

[LubosD]

@ErikEklund The glue has already been in place. The idea with this upgrade is to:

• Be closer to XNU in the wait queue implementation. The old glue was higher level, failed to implement important details and required changes in the calling code, because it lacked some functions completely. Now I'm trying to only provide low-level threading features to block (wait) and wake up a thread to the original code XNU wait queue code.
• Provide some missing IPC features that have cropped up over the years - mainly Mach vouchers.

Later upgrades would be done as needed, because 80% of XNU changes simply aren't relevant to us.

[bugaevc]

Is there some digestible explanation of vouchers? I can't understand what they're useful for.

[LubosD]

So far so good, darling shell runs with the new XNU. I will need to spend some time fixing stability issues - especially when things are shutting down.

@bugaevc It's a key-value collection represented by a Mach port. This exploit page explains some super simple (ab)usage.

They don't seem to be _critical_ to Darling. One of the use cases seems to be the ability to adopt scheduling properties of the sending task/thread, e.g. when talking to notifyd, so a high priority thread waiting on notifyd doesn't get slowed down just because notifyd itself isn't high priority.

I remember seeing something at least remotely related on Android & Binder.

[bugaevc]

It's a key-value collection represented by a Mach port. This exploit page explains some super simple (ab)usage.

I figured as much, and that post is all over Google search results for "Mach voucher". Apparently it's also a sealed store, so you can be sure it's not gonna change from under you once you've seen it.

I see it's mostly (only?) used by libdispatch for passing "continuations", which is... weird? Why does it need Mach IPC to pass data between threads inside a task?

One of the use cases seems to be the ability to adopt scheduling properties of the sending task/thread, e.g. when talking to notifyd, so a high priority thread waiting on notifyd doesn't get slowed down just because notifyd itself isn't high priority.

So, priority inheritance? But what does it have to do with vouchers, it sounds like something that should kick in whenever you're blocking on somebody's port?

I realize it wasn't you who designed vouchers, but maybe you've managed to figure more about them than me? Apple must have had some reasons to add them (and to repurpose the one-of-a-kind msgh_reserved field for passing them)?

[CuriousTommy]

Later upgrades would be done as needed, because 80% of XNU changes simply aren't relevant to us.

I was looking through the xnu-3789.41.3 source code and noticed that some of the arm64 code isn't there (darling-libplatform/src/cachecontrol/arm64/cache.S needs mach/arm/syscall_sw.h, which can be found in xnu).

Is it too late to use a newer kernel that includes the arm source code instead?

[LubosD]

@CuriousTommy Our LKM doesn't _really_ use much assembly code, it's just libkern/x86_64/OSAtomic.S and darling/continuation-asm.S. We also don't use syscall_sw.h.

[TheBrokenRail]

This has been merged, should this issue be closed?