efi bootmenu

[François Ozog]

Le mar. 28 déc. 2021 à 09:32, Simon Glass <sjg at chromium.org> a écrit :

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

EFI BootXXXX specify an array of device paths and boot options. A device
path is quite a unique construct despite its name.
A device path is itself an array of elements, some elements can be a file
path , configuration information, or diverse metadata. An example of
configuration information element is UART baud,stop bits, parity along with
terminal (vt100, ansi…). Another device path element can cover IP address,
transport information (tcp, UDP and port number).
The traditional EFI boot menu is quite crude and does not expose the full
capabilities of BootXXXX (lacks edit of boot options for instance!).

In the long run we will need to leverage all the BootXXXX capabilities and
those are EFI specific while being OS agnostic.
The other U-Boot boot methods (Android , ChromeOS…) are OS specific.
The goals are thus very different and making a generic approach seems quite
compromised. If there is a fully generic framework available in the future,
it may be possible to integrate the EFI boot menu. But at least there is a
need to solve, code first, the EFI complexities to fuel the generic
architecture discussion.

>
>
> 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
>
-- 
François-Frédéric Ozog | *Director Business Development*
T: +33.67221.6485
francois.ozog at linaro.org | Skype: ffozog