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

[Heinrich Schuchardt]

Am 5. April 2023 23:56:59 MESZ schrieb Mark Kettenis <mark.kettenis at xs4all.nl>:
>> 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.

Ubuntu has patched GRUB's devicetree command to call the protocol.

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


Currently a U-Boot boot option can define a kernel and an initrd to load. We could add the dtb location to the boot option in U-Boot.

>
>Also note that setting the BootOrder EFI variable from inside the OS
>isn't supported by most (all?) boards currently supported by U-Boot.

The approach discussed on the Linux side is to provide drivers that replace runtime calls and directly interface with the variable storage.

>So a convenient way to set the BootOrder EFI variable from within
>U-Boot is needed.

Please, have a look at the eficonfig and efidebug commands.

Best regards

Heinrich


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