Hi Masahisa, On Tue, 21 Dec 2021 at 00:37, Masahisa Kojima <masahisa.koj...@linaro.org> wrote: > > 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".
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
