After iBoot, code execution is controlled by us. What should be used as a second stage after that though?
One of the constraints is that servicing such a third-stage boot loader needs to go through macOS Recovery. That means that this stage is not easily serviceable.
Running regular kernels would require an abstraction layer in EL2 to hide differences in the underlying hardware. The most likely way would also make virtualisation inaccessible to the kernel as the consequence. As such, this solution isn’t considered here.
We have multiple choices:
- UEFI
Industry-standard, however Apple hardware differences will ensure that regular kernels will not run directly at EL2.
- pongoOS
Bespoke boot loader made as part of the checkra1n project. Small preemptive kernel. Of course not a standard.
- m1n1
Boot loader being made as part of the Asahi Linux project. Not a standard either.
- Linux as a bootloader
With kexec(), that’d be a possibly serious contender that reduces engineering effort. However, it might be a bit too heavyweight for this purpose.
- None
With kernel updates needing to go through macOS Recovery in that case, it’s not a realistic option.
Or, we might want to have two boot loader stages past iBoot, one of which could be upgradeable without going through macOS Recovery. For example, that’d be iBoot2 -> pongoOS -> UEFI.