[PATCH v5 3/8] bootstd: Support booting EFI where multiple options exist

[Mark Kettenis]

> Date: Wed, 5 Apr 2023 10:47:59 -0400
> From: Tom Rini <trini at konsulko.com>
> 
> On Wed, Apr 05, 2023 at 05:28:07PM +1200, Simon Glass wrote:
> > Hi Tom,
> > 
> > On Tue, 4 Apr 2023, 02:17 Tom Rini, <trini at konsulko.com> wrote:
> > 
> > > On Mon, Apr 03, 2023 at 12:56:49PM +0300, Ilias Apalodimas wrote:
> > > > On Sat, Apr 01, 2023 at 07:31:49PM +1300, Simon Glass wrote:
> > > > > Hi Tom,
> > > > >
> > > > > On Sat, 1 Apr 2023 at 07:02, Tom Rini <trini at konsulko.com> wrote:
> > > > > >
> > > > > > On Fri, Mar 31, 2023 at 10:25:56AM +1300, Simon Glass wrote:
> > > > > >
> > > > > > > The current EFI implementation has a strange quirk where it watches
> > > > > > > loaded files and uses the last-loaded file to determine the device
> > > that
> > > > > > > is being booted from.
> > > > > > >
> > > > > > > This is confusing with bootstd, where multiple options may exist.
> > > Even
> > > > > > > loading a device tree will cause it to go wrong. There is no API
> > > for
> > > > > > > passing this information, since the only entry into booting an EFI
> > > image
> > > > > > > is the 'bootefi' command.
> > > > > > >
> > > > > > > To work around this, call efi_set_bootdev() for EFI images, if
> > > possible,
> > > > > > > just before booting.
> > > > > > >
> > > > > > > Signed-off-by: Simon Glass <sjg at chromium.org>
> > > > > >
> > > > > > Shouldn't this all be a simple wrapper around the EFI Standard
> > > > > > BootDeviceOrder or whatever that's called?
> > > > >
> > > > > I think you are referring to boot manager, which isn't used here. This
> > > > > is replicating the existing distroboot functionality in standard boot.
> > > >
> > > > The distroboot functionality *was* trying to behave like the EFI spec
> > > > expects the bootmanager to behave.  Unfortunately I haven't had time to
> > > > review the distroboot patches closely, but back when this started, my
> > > point
> > > > was that EFI doesn't need anything.  Whenever the EFI flow is added
> > > bootstd
> > > > should 'just' call the bootmanager.
> > >
> > > Yes, this. We're trying make things cleaner overall, so the EFI portion
> > > of bootstd distro boot should just be "call EFI bootmanager" as that has
> > > a well defined standard way to specify what devices to try in what
> > > order.
> > >
> > 
> > We already call bootmgr in standard boot, if it is enabled.
> > 
> > But I am not sure how widely that is used...
> > 
> > This patch is about corner cases in the distro scripts. If we are to turn
> > these down we do need to try to do the same thing.
> 
> We probably need some distro people to chime in about what they're doing
> / expecting at this point in time? I would have sworn that the long term
> part of EFI "distro boot" would be using bootmgr since that's the
> standards based way to set boot order. And if you don't have a device
> tree in U-Boot, and want the distribution one, aren't you then using
> something like grub which has a "dtb" keyword to handle that on its own?
> That's not saying that "distro boot" doesn't need to load the device
> tree, for when it's then calling booti/bootz/bootm, but not for the EFI
> case these days? Or no?

The short anserwer is no.

The long answer:

OpenBSD requires EFI (booti/bootz/bootm only support booting Linux
kernels in various forms) but also relies on a proper device tree
being provided to its EFI bootloader.  While we have made significant
progress in having U-Boot provide a fully synched up device tree for
most of the SoCs that OpenBSD supports, we're not quite there yet, so
some people rely on U-Boot loading (and tweaking) an updated
device-tree from the EFI System Partition.

Our bootloader does have a "mach dtb" command to load a device tree
from the OpenBSD root partition, but this is considered to be a
debugging command and can't load a device tree from the EFI System
Partition.  Loading a device tree this way means the device tree does
not get tweaked by U-Boot, which is problematic on some SoCs/boards.

We now have the EFI_DT_FIXUP_PROTOCOL, but our bootloader doesn't use
this yet.  If the consensus is that distroboot-with-efiboot needs to
deprecated I can work on supporting that protocol in our bootloader.
But a release of OpenBSD with support for that will not be available
until november 2023.

Alternatively bootmgr could implement the device tree loading and
fixup.  Or the bootstd stuff could do this before starting bootmgr.  I
understand the concerns about loading device trees from disk when
secure boot is enabled.  So maybe this should only be done when secure
boot is disabled.

Also note that setting the BootOrder EFI variable from inside the OS
isn't supported by most (all?) boards currently supported by U-Boot.
So a convenient way to set the BootOrder EFI variable from within
U-Boot is needed.

Cheers,

Mark

P.S. Does grub support the EFI_DT_FIXUP_PROTOCOL these days?  If not
     (or if your Linux distro still ships with an older version of
     grub) you'll face the same issue as OpenBSD regarding the lack of
     fixups for loaded devictrees.