binja_kc VS xnu

In theory I have all of those, but currently I have none, so it's manual work. Your best friend in diagnosing a kernel crash is a KDK. If you have one that matches your build, it will have symbols in it. With a little bit of math you can take the backtrace in the crash log and slide it appropriately to match the binary. Personally I use LLDB for this. Here's an example of what this looks like on an x86-64 kernel (Apple silicon has its own math but it's largely the same): https://github.com/saagarjha/unxip/issues/14#issuecomment-10.... The kernel is typically compiled with optimization, so there's a lot of inlining and code folding, but with function names, source files, and instruction offsets it's pretty trivial to match it to the code Apple publishes.

In this case I do not have a KDK for that build. In fact Apple has been unable to produce one for a couple of months, a inadequacy which I have repeatedly emphasized to them because of how critical they are for stuff like this. Supposedly they are working on it. Whatever; in lieu of that I got to figure out how good the tooling for analyzing kernels is these days, which was my real goal anyways.

For this crash log I downloaded the IPSW file for your build, 22A400. All of them get linked on The iPhone Wiki, e.g. https://www.theiphonewiki.com/wiki/Firmware/Mac/13.x. Once you unpack the IPSW (it's a zip file) there are compressed kernelcache files inside. Apple changed the format of these this year so most of the tooling breaks on it, but https://github.com/blacktop/ipsw was able to decompress them. Then I loaded it in to Binary Ninja, which apparently doesn't support them either but compiling this person's plugin (+166 submodules, and a LLVM & Boost build) gets it to work: https://github.com/skr0x1c0/binja_kc.

From there you can load up the faulting address from the crash log and see what the function looks like. In this case, a bunch of junk has been inlined into it but there's a really obvious and fairly unique string reference for "invalid knote %p detach, filter: %d". From there, you can compare it against the actual source code to see which one matches the "shape" of the function you're looking at. I happened to also pull up an older kernel which did have a KDK available and then compared its assembly to the new one to match it up to ptsd_kqops_detach. The disassembly of the crashing code is obviously doing a linked list walk so you can figure out exactly which line it is from that.

If I wasn't lazy I might also fire up a debugger to see why the function had walked off the end of the list but without KDKs things get pretty bad, not that they're very good to begin with. I don't have a m1n1 setup (I should probably do this at some point) and the things I do have, like remote debugging or the VM GDB stub, are not really worth suffering through for a Hacker News comment.

> That said--in support of "not in a vacuum", and against myth-making.

Apple knows what they owe to open source software: https://opensource.apple.com/releases/

A lot of the core XNU and Darwin code is open source: https://opensource.apple.com/releases/

> When I'm seeing a weird network issue, I want to be able to peer into the kernel's tcp stack.

Uhh...

https://github.com/apple-oss-distributions/xnu/tree/xnu-8796...

I think NeXT might've written an HFS Standard reader or something, but they used the Apple code for HFS+ so it ended up as a hybrid.

https://github.com/apple-oss-distributions/xnu/blob/rel/xnu-...

Mach message passing and objc message passing have no relation. I don’t think xnu contains much if any objc.

Obviously not all of its, but they contribute quite a bit. https://opensource.apple.com/releases/

here is the kernel source (they have branches for each individual macos release with its darwin kernel ver, macos 13 is ver 8792.xx.x for instance): https://github.com/apple-oss-distributions/xnu

Apple does plenty of open source stuff. Safari's browser engine, Swift, libdispatch, the XNU kernel used by iOS and macOS, etc. And macOS is generally packed with open source things, like the default shell, zsh. Also, Metal actually predates Vulkan, so Vulkan was definitely not established when they started focusing on Metal. Yeah, they probably should consider supporting Vulkan now, but it's nothing to do with open source. The main beneficiaries of Apple supporting Vulkan would be people porting closed-source games.