[marcan_42]

That's mostly just imported from existing iPhone research, where people have been reverse engineering iBoot (from exploitable phones, since it's encrypted) for a long time now. Combining that with what is known about how the M1 works from observation / the boot config data structures yields a decent picture, without actually seeing the code.

Here's a fun one though: how I found and documented the Apple-proprietary memory compression/uncompression instructions.

https://twitter.com/marcan42/status/1362450439845781505

A lot of the hardware research ends up looking like this; twiddle random bits and see what happens. For more complex drivers (e.g. the GPU), my plan is to run macOS under a thin hypervisor built on m1n1 that can log hardware accesses.

[ur-whale]

>my plan is to run macOS under a thin hypervisor built on m1n1 that can log hardware accesses

The fact that people like you exist in this world really makes me happy.

[hatsunearu]

If you read the post, the guy says that is the same approach used to make the nouveau nvidia drivers.

[marcan_42]

They do it in-kernel (with a Linux patch and the Linux drivers) instead of a hypervisor, but it's the same overall idea.

I could do it that way too (XNU is vaguely open source, and the most recent source release is buildable for M1), but I honestly find the idea of writing a little hypervisor a lot more appealing than learning to hack on XNU, and it's probably a similar amount of effort all things considered.

Technically, m1n1 is already a "hypervisor" for very small values of hypervisor; as of last week you can `chainload.py --el1` another m1n1 into VM guest mode and run a kernel from there, and will get exception report dumps if it crashes in a way a hypervisor would notice, but there is no virtual memory in use. So it's mostly just taking that, making some page tables, adding exception handlers to handle page faults and and log MMIO as I want to, and somewhat virtualizing the CPU startup hardware (which is the only thing we can't just pass through because we need to control the CPU boot process). And making chainload.py able to load macOS kernels (needs some extending to support missing Mach-O features and handling some memory structures properly).