On 19/12/2022 04.40, Heinrich Schuchardt wrote:
The MacBooks only have one drive. Why would you want two ESPs on one drive?
The boot model of these machines is fundamentally different from EFI.
There is top-level, built-in multiboot support. The boot stages are:
=== global === 1. iBoot1 (global bootloader + global firmware) === per OS / security context === 2. iBoot2 (OS loader + runtime firmware) 3. Whatever we want
Global firmware has ABI compatibility guarantees, but runtime firmware does not. That means that runtime firmware must be, to some extent, paired to the OS that is running under it. macOS implements this by always upgrading firmware in tandem with the OS. We implement this by having our OS support a subset of "blessed" firmwares, and automatically selecting the correct firmware for a to-be-installed OS at installation time.
We do *not* control the firmware load process and we *cannot* replace already running firmware with our own.
We extend this system by provisioning an EFI environment as step 3. This allows downstream OSes to use a more familiar boot environment. But since this EFI environment is *necessarily* tied to what the prior boot stages consider to be *one* OS with *one* set of firmware, running multiple OSes under the same EFI environment is a problem. There are also likely to be further issues in the future once we start integrating more with the platform's secure boot and SEP (think TPM) support, since from its point of view one top-level OS is one OS, not several.
Hence, multiple ESPs, one per top-level OS, with users expected to only install one persistent OS to each ESP (but retaining the ability to e.g. boot from USB for recovery, under the understanding that live-booted OSes would have to support the firmware in question and aren't going to try to do system management tasks that are the responsibility of the owner OS).
Additionally, this setup lets us define device trees and update the m1n1 second-stage loader with each OS, which is particularly important until all DT schemas are stabilized, since we can't guarantee backwards compatibility between DTs and OSes (although we try, we do have to break it sometimes). The DT, m1n1 (which populates runtime DT options), u-boot (DT consumer), and the OS (DT consumer) are all involved in this process, and need to be compatible to varying degrees. If the installed OS owns the ESP, it can take responsibility for updating the DT/m1n1/u-boot together with itself, which solves the compatibility issue (and makes the whole thing way more seamless for users).
I know "multiple ESPs" sounds weird in the context of traditional EFI systems, but it's the best we could come up with to shoehorn EFI into this very-much-not-EFI platform.
Further reading: https://github.com/AsahiLinux/docs/wiki/Open-OS-Ecosystem-on-Apple-Silicon-M...
Why can't the Asahi team use the current UEFI bootflow? We should avoid unneeded deviations. Can the current deviations be removed in Asahi Linux?
If you can come up with a better idea that actually works on these platforms and solves all the issues I mentioned above, I'm all ears.
- Hector