efi bootmenu

[Simon Glass]

Hi Masahisa,

On Tue, 21 Dec 2021 at 00:37, Masahisa Kojima
<masahisa.kojima at linaro.org> wrote:
>
> Hi Takahiro,
>
> On Tue, 21 Dec 2021 at 11:47, Takahiro Akashi
> <takahiro.akashi at linaro.org> wrote:
> >
> > On Mon, Dec 20, 2021 at 06:25:05PM +0900, Masahisa Kojima wrote:
> > > Hi Heinrich, Ilias, Akashi-san,
> > >
> > > Ilias and I are now discussing to create efi bootmenu, almost similar
> > > to UiApp in EDK2.
> >
> > Why not discuss this topic openly in ML?
>
> Yes, I included U-Boot ML.(Sorry, I should include from the the beginning.)
>
> >
> > How is this feature related to Simon's bootmethod proposal?
>
> If I correctly understand Simon's bootmethod proposal,
> the difference is that efi bootmenu only targets to implement
> the menu based UI to select/edit/add/delete "Boot####" and "BootOrder".

Yes, EFI would be one of the bootmethods. Others would be U-Boot
scripts, Chrome OS, Android, etc. plus people might add custom ones.

Also I am thinking that (perhaps) the bootdev part of the standard
boot thing could be used to provide boot devices for EFI.

If we do have a bootmenu, I wonder if it could be generic, instead of
tied to EFI?

Regards,
Simon


>
> >
> > > Here is some background.
> > > ===
> > > U-Boot's command line should be completely disabled on secure devices.
> > > However since U-Boot doesn't (yet) support EFI runtime SetVariable
> > > for all supported devices, disabling the command line is hard, if even possible.
> > > If we provide a boot menu, with access to very limited functionality, e.g select
> > > a boot option and allow users to add/edit/delete existing options,
> > > we can enhance security and provide a usable alternative to the users.
> > >
> > > In addition, if we can add options for managing EFI keys and enabling
> > > disabling secure boot, we can completely get rid of the u-boot cmd line,
> > > greatly enhancing platform security
> >
> > Basically, it will be a good idea.
> > Please keep in mind, however, that add/deleting boot options,
> > [en|dis]abling secure boot or modifying secure variables should
> > belong to some sort of privileged operations.
> > I think that we need to have some mechanism to distinguish them
> > from other menus. It might be system specific, though.
> >
> > > ===
> > >
> > > I am planning to hook the existing "bootefi bootmgr" boot process.
> > > In "bootefi bootmgr", the planned process will be as follows.
> > >  1) check "BootNext"
> >
> > What do you mean by "check"?
>
> I meant the existing bootmgr implementation. If "BootNext" is
> specified, system boots with "BootNext".
>
> >
> > >  2) show efi bootmenu (*NEW*)
> > >  3) if user quits efi bootmenu, then boot in accordance with "BootOrder"
> > > It means efi bootmenu is native u-boot program.
> > >
> > > I would like to hear your opinion how this efi bootmenu should be implemented.
> > > Is it better to implement as EFI application?
> >
> > In my personal opinion, we should implement the feature as a separate
> > EFI application. One of benefits of UEFI interfaces are the ability
> > to expand functionality with driver modules and applications without
> > modifying the core.
> > (One example is iPXE boot that Heinrich often picks up in his comments.)
> >
> > If it is an EFI application, it can be easily replaced with others
> > per system and we may be able to use secure boot to authorise the app
> > itself.
>
> Thank you, I understand the benefit of implementing as EFI App.
>
> >
> > But implementing it as an EFI app is not the goal, and I think you can
> > start with what you want to do first.
> >
> > > Note that  I tried to run edk2 UiApp on U-Boot, I found that the
> > > following protocol
> > > are required and assertion occurs in DEBUG build.
> > >   gEfiHiiConfigRoutingProtocolGuid
> > >   gEfiHiiFontProtocolGuid
> > >   gEfiHiiImageProtocolGuid
> > > Probably these protocols can be implemented as dummy stub.
> > > If I run UiApp in RELEASE build,  I encounter exception on UiApp,
> > > I have not debugged it.
> >
> > I didn't investigate this failure in details before, but it might be
> > related to a (bogus) device path installed into the efi image which
> > is to be loaded into and invoked from the main memory.
> >
> > -Takahiro Akashi
> >
> > > Regards,
> > > Masahisa Kojima
>
> Thanks,
> Masahisa Kojima