For USB I mean USB2 on the Type C ports (device/host) and USB3 on the Mac Mini's A ports (which are just a standard discrete PCIe controller). USB3 and Thunderb

For USB I mean USB2 on the Type C ports (device/host) and USB3 on the Mac Mini's A ports (which are just a standard discrete PCIe controller). USB3 and Thunderbolt/USB4 require more work to integrate the Type C port management, muxing, and bringing up the associated PCIe controllers; we're working on those things (and Corellium also have a PoC for that, it's not that hard either, but as everything it takes time to do it right). We're also working on making changes to the Linux IOMMU subsystem to enable DART with 16K pages to work with kernels built with a 4K page size, which will solve a lot of use cases (Android apps, x86 apps under FEX emu, and not having to pester distros to ship 16K page size kernels to get TB3/USB4 to work safely). Sven sent out a draft patch series for that to Linux a few days ago, and the first take on DART itself is already upstream. Also, just hours ago Alyssa lit up display modesetting with DCP under Linux with KMS, for the first time outside of macOS and our prototype m1n1 driver. So 4K displays now work with proper page flipping, and we're moving past the bootloader-provided framebuffer. After taking a crack at the GPU kernel driver, I should probably direct my attention to audio (which nobody has looked at yet); if whenever we demo a fully accelerated 3D desktop I can have that working too it'll avoid a lot of people coming out and saying "they don't even have working audio, nobody's ever going to use it" ;) For reverse engineering, as I mentioned, one big tool I spent a month writing is a custom thin hypervisor that can run macOS (the native version, not the VM kernel version) with direct access to the hardware. It boots to desktop with all drivers intact, and this allows us to write hypervisor hooks to inspect and log all MMIO traffic. We already have a working tracer for the DCP (display controller coprocessor) that logs all inter-processor calls, which is how I figured out that bit, as well as generic parts of the interface they use for all coprocessors. Next up is the GPU, so I'll just point the base copro tracer at the GFX core and also trace all MMIO registers in those ranges and see what macOS does. It really does make life much easier. It's also great for debugging Linux; it implements a virtual UART over USB-gadget, so you don't need special cables to get a physical UART, and you get low-level debugging features for when your kernel crashes. Our kernel test cycle is on the order of 7-10 seconds, including rebooting the machine and loading a new kernel from a host machine on top of the hypervisor. I made a long video about all the HV stuff, if you're interested: https://www.youtube.com/watch?v=igYgGH6PnOw https://www.youtube.com/watch?v=igYgGH6PnOw BootPolicy is managed using the `bputil` command, which has an official manpage: https://keith.github.io/xcode-man-pages/bputil.1.html https://keith.github.io/xcode-man-pages/bputil.1.html To install a custom kernel you use kmutil, which is similarly documented (look for `configure-boot`): https://keith.github.io/xcode-man-pages/kmutil.8.html https://keith.github.io/xcode-man-pages/kmutil.8.html Apple also has general documentation on the LocalPolicy fields. "coih" is the one you're looking for, it literally means "CustomOS Image4 Hash". https://support.apple.com/guide/security/contents-a-localpolicy-file-mac-apple-silicon-secc745a0845/web https://support.apple.com/guide/security/contents-a-localpol... Here's an unofficial blog maintained by (apparently) Apple engineers detailing how to install a custom build of XNU using these mechanisms: https://kernelshaman.blogspot.com/2021/02/building-xnu-for-macos-112-intel-apple.html https://kernelshaman.blogspot.com/2021/02/building-xnu-for-m... That's the "official" line why this all exists, being able to run self-built XNU kernels, but it is evident that internally Apple engineers are happy to see efforts to port Linux, and Apple themselves have no reason to oppose that use case. It's all very clearly a "we won't help you, but have fun" kind of understanding. And we intend to have fun :) Realistically, once this runs well enough and people are actually using it, that does put pressure on Apple not to do anything that gratuitously would seriously make our lives harder, whether they ever officially admit to that or not.