RFC: Handling of multiple EFI System Partitions

[Hector Martin]

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-Macs

> 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