efi bootmenu

[Masahisa Kojima]

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

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