[PATCH 6/8 v2] efi_loader: Replace config option with EFI variable for initrd loading

[Ilias Apalodimas]

On Tue, 5 Jan 2021 at 10:50, Ilias Apalodimas
<ilias.apalodimas at linaro.org> wrote:
>
> Akashi san,
>
> On Tue, Jan 05, 2021 at 11:42:22AM +0900, AKASHI Takahiro wrote:
> > On Wed, Dec 30, 2020 at 05:07:18PM +0200, Ilias Apalodimas wrote:
> > > Up to now we install EFI_LOAD_FILE2_PROTOCOL to load an initrd
> > > unconditionally. Although we correctly return various EFI exit codes
> > > depending on the file status (i.e EFI_NO_MEDIA, EFI_NOT_FOUND etc), the
> > > kernel loader, only falls back to the cmdline interpreted initrd if the
> > > protocol is not installed.
> > >
> > > This creates a problem for EFI installers, since they won't be able to
> > > load their own initrd and continue the installation. It also makes the
> > > feature hard to use, since we can either have a single initrd or we have
> > > to recompile u-boot if the filename changes.
> > >
> > > So let's introduce a different logic that will decouple the initrd
> > > path from the config option we currently have.
> > > When the EFI application is launched through the bootmgr, we'll try to
> > > match the BootCurrent value to an Initrd#### EFI variable.
> > > e.g Boot0000 -> Initrd0000, Boot0010 -> Initrd0010 etc.
> >
> > Do you think this semantics be kept U-boot specific?
> > It seems that it can work for any other EFI firmware (implementation).
> >
>
> The GUID is very linux specific and it's meant to load an initrd, but I guess
> any OS that uses a 'helper' file to load the final OS can be supported.
>
> > > The Initrd#### EFI variable is expected to include the full file path,
> > > i.e 'mmc 0:1 initrd'.  If the file is found, we'll install the
> >
> > If so, the content of "Initrd####" should contain a generic EFI
> > representation of file path.
> > Please note that "Boot####" internally contains a flattened string of
> > "EFI device path" to the image while efidebug command accepts a style of
> > "mmc 0:1 image" as arguments to "efidebug boot add" sub-command.
>
> Thanks for the pointers. I've already changed the patchset and using exactly
> what you described. This has another advantage, all the helper files for the
> string parsing previous patches introduce, went away as well.
>

While I was trying to code this I came across a few things that we
need to resolve before posting my v3.
This feature is supposed to be very specific in linux so each OS
loader can decide on how to expose and
load the corresponding initrd.

Moving the contents to a device path adds more problems that it solves
at the moment.
First of all we'll be forced to use efi_load_image_from_file(), which
uses EFI_SIMPLE_FILESYSTEM_PROTOCOL
and EFI_FILE_PROTOCOL to eventually load the file. This has 2
problems. We'll have to place the initrd on the same
filesystem the image we load resides (as opposed to my patch where the
initrd can be anywhere).
Apart from that calling efi_load_image_from_file() will try to free
the memory on errors, but that memory is allocated
and managed by the efi-stub.

I'd prefer keeping the implementation as is, unbless someone has a better idea.

Thoughts?

Cheers
/Ilias


[...]