Hi Takahiro, On Tue, 21 Dec 2021 at 11:47, Takahiro Akashi <takahiro.aka...@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