[PATCH v2] bootstd: Make efi_mgr bootmeth work for non-sandbox setups

[Mark Kettenis]

> From: Simon Glass <sjg at chromium.org>
> Date: Thu, 7 Sep 2023 09:57:34 -0600
> 
> Hi Mark,
> 
> On Thu, 7 Sept 2023 at 07:08, Mark Kettenis <mark.kettenis at xs4all.nl> wrote:
> >
> > > From: Simon Glass <sjg at chromium.org>
> > > Date: Thu, 7 Sep 2023 06:23:10 -0600
> > >
> > > Hi Mark,
> > >
> > > On Sun, 3 Sept 2023 at 14:40, Mark Kettenis <kettenis at openbsd.org> wrote:
> > > >
> > > > Enable the bootflow based on this bootmeth if the BootOrder EFI
> > > > variable is set.
> > > >
> > > > Signed-off-by: Mark Kettenis <kettenis at openbsd.org>
> > > > ---
> > > >
> > > > ChangeLog:
> > > >
> > > > v2: - Initialize EFI subsystem to populate EFI variables
> > > >
> > > >
> > > >  boot/bootmeth_efi_mgr.c | 17 ++++++++++++++++-
> > > >  1 file changed, 16 insertions(+), 1 deletion(-)
> > > >
> > > > diff --git a/boot/bootmeth_efi_mgr.c b/boot/bootmeth_efi_mgr.c
> > > > index e9d973429f..e6c42d41fb 100644
> > > > --- a/boot/bootmeth_efi_mgr.c
> > > > +++ b/boot/bootmeth_efi_mgr.c
> > > > @@ -14,6 +14,8 @@
> > > >  #include <bootmeth.h>
> > > >  #include <command.h>
> > > >  #include <dm.h>
> > > > +#include <efi_loader.h>
> > > > +#include <efi_variable.h>
> > > >
> > > >  /**
> > > >   * struct efi_mgr_priv - private info for the efi-mgr driver
> > > > @@ -46,13 +48,26 @@ static int efi_mgr_check(struct udevice *dev, struct bootflow_iter *iter)
> > > >  static int efi_mgr_read_bootflow(struct udevice *dev, struct bootflow *bflow)
> > > >  {
> > > >         struct efi_mgr_priv *priv = dev_get_priv(dev);
> > > > +       efi_status_t ret;
> > > > +       efi_uintn_t size;
> > > > +       u16 *bootorder;
> > > >
> > > >         if (priv->fake_dev) {
> > > >                 bflow->state = BOOTFLOWST_READY;
> > > >                 return 0;
> > > >         }
> > > >
> > > > -       /* To be implemented */
> > > > +       ret = efi_init_obj_list();
> > >
> > > Doesn't this start up the whole EFI system? Is there a cheaper way to
> > > see if the variable subsystem exists, or can work?
> >
> > A fair bit of it at least.  With the possible exception of launching
> > EFI capsules (which shouldn't happen for a "normal" boot), I don't
> > think this is very expensive though.
> >
> > There currently isn't a way to only initialize the variable subsystem;
> > we can't just call efi_init_variables() here since we have to also
> > call efi_disks_register() and a later efi_init_obj_list() call would
> > call efi_init_variables() again, which would leak memory.
> >
> > Alternatively we could just unconditionally declare the efi_mgr
> > bootmeth as "ready" (like you already do for sandbox).  That would
> > postpone initialization of the EFI subsystem until we actually execute
> > this bootmeth.
> >
> > But we need to do something before we switch more targets to standard
> > boot since otherwise booting through the EFI boot manager is just
> > plain broken.
> 
> Yes...
> 
> I don't have any great ideas on this. If we could get the EFI code
> better integrated into U-Boot then perhaps we would not need this
> 'monolithm' init?

You'll have to take that up with the maintainers of the EFI loader
subsystem.  I just want to repair the breakage that was introduced
with bootstd.