[RFC PATCH 2/3] efi_loader: efi_loader: Replace config option for initrd loading

[Ilias Apalodimas <ilias.apalodimas@linaro.org>]

Akashi-san,

On Thu, Jan 14, 2021 at 01:23:30PM +0900, AKASHI Takahiro wrote:
> Ilias,
> 
> On Wed, Jan 13, 2021 at 01:11:48PM +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 defining a UEFI BootXXXX we can use the filepathlist and store
> > a file path pointing to our initrd. Specifically the EFI spec describes:
> > 
> > "The first element of the array is a device path that describes the device
> > and location of the Image for this load option. Other device paths may
> > optionally exist in the FilePathList, but their usage is OSV specific"
> 
> I wonder what "OSV specific" does and should mean.

Judging from the context is used, I assumed it meant OS vendor.

> Apparently, using a "array of device paths" is U-Boot specific for now
> and any distro who wants to use U-Boot as an EFI boot loader needs to
> (at least, preferably) take care of this. It would be sad
> that the installation process cannot be EFI-implementation agnostic
> in terms of EFI's purpose.
> 

That's the reason I changed the approach completely. This one adheres to the
EFI spec compared to the previous version that used EFI variables.

> So do you intend to propose your idea as a common practice to linux community?

Yes, although that depends on the definition of the linux community.
The kernel itself is irrelevant here. We need to make sure though that
applications like efibootmgr follow the same principle.

> 
> > When the EFI application is launched through the bootmgr, we'll try to
> > interpret the extra device path. If that points to a file that exists on
> > our disk, we'll now install the load_file2 and the efi-stub will be able
> > to use it.
> > 
> > This opens up another path using U-Boot and defines a new boot flow.
> > A user will be able to control the kernel/initrd pairs without explicit
> > cmdline args or GRUB.
> > 
> > Signed-off-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
> > ---
> >  cmd/bootefi.c                    |   3 +
> >  include/efi_loader.h             |   1 +
> >  lib/efi_loader/Kconfig           |  13 +--
> >  lib/efi_loader/efi_bootmgr.c     |   3 +
> >  lib/efi_loader/efi_load_initrd.c | 154 ++++++++++++++++---------------
> >  5 files changed, 91 insertions(+), 83 deletions(-)
> > 
> > diff --git a/cmd/bootefi.c b/cmd/bootefi.c
> > index fdf909f8da2c..053927d5d986 100644
> > --- a/cmd/bootefi.c
> > +++ b/cmd/bootefi.c
> > @@ -357,6 +357,9 @@ static efi_status_t do_bootefi_exec(efi_handle_t handle, void *load_options)
> >  
> >  	free(load_options);
> >  
> > +	if (IS_ENABLED(CONFIG_EFI_LOAD_FILE2_INITRD))
> > +		efi_initrd_deregister();
> > +
> 
> I understand why you want do "deregister" the initrd handle,
> but the handle for the loaded image is still valid at this point.
> So it looks inconsistent from the viewpoint of API's.
> 

Hmm why? Won't this code be called after efi_exit()? In that case the loaded
image handle is deleted as well.

> >  	return ret;
> >  }

[...]

> > @@ -222,6 +222,9 @@ static efi_status_t try_load_entry(u16 n, efi_handle_t *handle,
> >  		ret = efi_set_variable_int(L"BootCurrent",
> >  					   &efi_global_variable_guid,
> >  					   attributes, sizeof(n), &n, false);
> > +		/* try to register load file2 for initrd's */
> > +		if (IS_ENABLED(CONFIG_EFI_LOAD_FILE2_INITRD))
> > +			ret |= efi_initrd_register();
> 
> I think that, even if the config(EFI_LOAD_FILE at _INITRD) is turned on,
> we should be allowed to boot linux without initrd if we want.
> In addition, we may want to boot non-linux images by using U-boot 
> with the config enabled.
> 

That was the case with the previous patchset.  The efi_initrd_register() was
always returning EFI_SUCCESS. Heinrich asked me respect the bootmgr behavior,
since a distro without initrd will most likely fail to boot, so he wanted to
allow fallbacks on the bootmgr.

The reasoning is that the kernel, in EFI mode, has 3 ways of discovering an
iniitrd.
1. Fixups on initrd-start/end in the DTB. In that case the stub is unaware of
how the DTB gets loaded
2. initrd=XXXX in the command line. In that case the kernel uses
EFI_SIMPLE_FILESYSYSTEM_PROTOCOL to load the parsed file. 
3. The load option this patch implements via LOAD_FILE2

If the user specifies an initrd, he needs it to boot and it's unlikely to specify 
both the initrd=xxxxx and add it in the Boot#### variable. 

I think I can fix the use case and return EFI_SUCCESS from
efi_initrd_register() if the extra instance is not found in the device path
array. In that case a user will be able to boot without it, but if the device
path is specified, the file *must* be there. If it's not the bootmgr will 
fallback to the next available boot option.

> >  		if (ret != EFI_SUCCESS) {
> > +		status = EFI_NOT_FOUND;

[...]

> >  		goto out;
> 
> The logic here (efi_get_fp_from_boot, then efi_file_from_path)
> is also seen in check_initrd(). Pls refactor the code.

check_initrd() closes the file handle though and frees the device path. It's
supposed to serve as a wrapper for 'is the file present', while in the second
function we need the device path and the file handle to load the file.

Thanks for taking the time to review this.

Regards
/Ilias