RFC: Handling of multiple EFI System Partitions

* RFC: Handling of multiple EFI System Partitions
@ 2022-12-18 14:21 Mark Kettenis
  2022-12-18 19:40 ` Heinrich Schuchardt
  0 siblings, 1 reply; 8+ messages in thread
From: Mark Kettenis @ 2022-12-18 14:21 UTC (permalink / raw)
  To: u-boot; +Cc: xypron.glpk, ilias.apalodimas, sjg, marcan, j

The Asahi installer, which is what most people use to get their Apple
Silicon Mac into a state where it is possible to install another OS on
the machine, offers the posibility to create multiple OS installs.
For each of these it creates a separate APFS partition (which holds
among other things, some essential system firmware) and separate EFI
System Partitions.  This has a few benefits:

* It allows control over which version of the system firmware is used
  by the OS.  This is especially important for things like the GPU and
  DCP (display controller) firmware, where the firmware interface
  isn't exactly what we'd call "stable".  This way system firmware is
  paired with the OS install (similar to what macOS does for itself)
  which prevents breaking other OS installs on the same disk.

* It allows us to store a 2nd stage bootloader (m1n1+u-boot+dtb) on
  the EFI System Partition (ESP) such that it can be easily upgraded
  from within Linux without affecting other OS installs on the same
  disk.

* It allows the use of the "native" boot picker to switch between
  OSes.

The approach the Asahi team has taken is to pair the APFS partition
with the ESP by adding a proprty that contains the partition UUID to
the device tree.  The installer ships u-boot with a patched distro
boot script that looks at this device tree property, figures out what
the right ESP is and loads the EFI bootloader
(efi/boot/bootaarch64.efi) from that partition.

This approach has some drawbacks:

1. U-Boot will still consider the first ESP as *the* ESP, which means
   that the ubootefi.var file is still read from and written from the
   first ESP.

2. The distro boot script modifications don't work if U-Boot's
   built-in efibootmgr is used.  This probably also affects Simon's
   bootstd stuff.

So my idea is to have U-Boot recognize the device tree property and
use it when it determines what partition is *the* ESP.  A proof of
concept diff is attached below.  This probably needs a bit of
massaging as reading the device tree property in generic EFI code like
this is probably not acceptable.  A better approach might be to have a
function that can be called from board-specific code that sets the UUID.

Thoughts?  Would such a feature be useful on other hardware platforms?


commit 088f5626d4347cef76ad5a54477944886efb005a
Author: Mark Kettenis <kettenis@openbsd.org>
Date:   Sun Sep 25 01:57:24 2022 +0200

    HACK: Use designated ESP
    
    Signed-off-by: Mark Kettenis <kettenis@openbsd.org>

diff --git a/lib/efi_loader/efi_disk.c b/lib/efi_loader/efi_disk.c
index 7ea0334083..86b867d319 100644
--- a/lib/efi_loader/efi_disk.c
+++ b/lib/efi_loader/efi_disk.c
@@ -523,6 +523,27 @@ static efi_status_t efi_disk_add_dev(
 				  desc->devnum, part);
 		}
 	}
+
+	ofnode chosen_node;
+	const char *uuid = NULL;
+	chosen_node = ofnode_path("/chosen");
+	if (ofnode_valid(chosen_node)) {
+		uuid = ofnode_read_string(chosen_node,
+					  "asahi,efi-system-partition");
+	}
+
+	/* Store designated EFI system partition */
+	if (part && uuid && strcmp(uuid, part_info->uuid) == 0) {
+		if (part_info->bootable & PART_EFI_SYSTEM_PARTITION) {
+			efi_system_partition.uclass_id = desc->uclass_id;
+			efi_system_partition.devnum = desc->devnum;
+			efi_system_partition.part = part;
+			EFI_PRINT("EFI system partition: %s %x:%x\n",
+				  blk_get_uclass_name(desc->uclass_id),
+				  desc->devnum, part);
+		}
+	}
+
 	return EFI_SUCCESS;
 error:
 	efi_delete_handle(&diskobj->header);

^ permalink raw reply related	[flat|nested] 8+ messages in thread