[PATCH] efi_loader: improve detection of ESP for storing UEFI variables

[Mark Kettenis]

> From: Heinrich Schuchardt <xypron.glpk at gmx.de>
> Date: Mon, 9 Nov 2020 15:36:33 +0100
> 
> On 09.11.20 14:51, Mark Kettenis wrote:
> >> From: Paulo Alcantara <pc at cjr.nz>
> >> Date: Mon, 09 Nov 2020 10:24:08 -0300
> >>
> >> Heinrich Schuchardt <xypron.glpk at gmx.de> writes:
> >>
> >>> On 09.11.20 00:58, Paulo Alcantara wrote:
> >>>> The UEFI specification does not restrict on the number and location of
> >>>> ESPs in a system.  They are discovered as required by looking at the
> >>>> partition type, but firmware implementations are allowed to support
> >>>> ESPs which do not contain a valid partition type.
> >>>
> >>> I guess you refer to chapter "13.3.3 Number and Location of System
> >>> Partitions" of the UEFI spec saying: "Further, UEFI implementations
> >>> may allow the use of conforming FAT partitions which do not use the
> >>> ESP GUID."
> >>
> >> Yep, sorry.  Thanks for pointing it out!
> >>
> >>> Why should U-Boot support FAT partitions that are not of type FAT 0xef
> >>> and GPT partition that do not use the ESP GUID?
> >>
> >> In most UEFI (EDK2-based) systems I used, I could boot my OSes and
> >> diagnostic tools by simply having a supported filesystem (FAT12/16/32)
> >> and /EFI/BOOT/BOOT{ARCH}.EFI file and never cared about setting the
> >> partition type at all.  It took me a while for figuring out why I
> >> couldn't get my UEFI variables loaded from my FAT partition that
> >> contained /ubootefi.var and /EFI/BOOT/BOOTAA64.efi files.
> >
> > The OpenBSD installation media for armv7 and arm64 use a FAT partition
> > of type 0x0c because the Raspberry Pi firmware doesn't support 0xef.
> > This allows us to have a single FAT partition with the Raspberry Pi
> > firmware, U-Boot and /EFI/BOOT/BOOT{ARCH}.EFI.
> >
> > So far this works on all UEFI firmware I've tried (EDK2, U-Boot and
> > AMI AptioV UEFI).
> >
> 
> The issue Paulo was addressing is that U-Boot only persists non-volatile
> UEFI variables if it can find a partition indicated as ESP by the
> partition type.
> 
> This becomes interesting if you want to have both Linux and OpenBSD on
> the same device and you want to use UEFI boot variables to decide which
> operating system to boot or if you want to use secure boot.
> 
> On Debian the ESP is an 0xef partition mounted at /boot/efi.
> 
> SUSE recommends the same:
> https://www.suse.com/support/kb/doc/?id=000017007
> https://documentation.suse.com/sles/15-SP1/html/SLES-all/cha-uefi.html
> 
> For a Raspberry I typically would have the following partitions:
> 
> / - root file system
> /boot/firmware - *first* FAT partition
> /boot/efi - ESP, FAT formatted
> 
> As /boot/firmware and /boot/efi can be separate partitions with
> different partition type why does OpenBSD not use this scheme?

Two reasons:

1. The installer and the scripts that build the installer image only
   support creating a single FAT partition.

2. Adding another FAT partition would consume another slot in the
   disklabel[1] which doesn't have a lot of empty slots left for a
   default install.

Cheers,

Mark

[1] A disklabel is the platform-independent partition table that is
    used by BSD systems and for example Solaris on SPARC.