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

[Heinrich Schuchardt <xypron.glpk@gmx.de>]

On 06.01.21 11:43, Ilias Apalodimas wrote:
> On Tue, 5 Jan 2021 at 10:50, Ilias Apalodimas
> <ilias.apalodimas@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

You are not obliged to call efi_load_image_from_file(). You could
implement your own function.

Or you could add a check *buffer!=NULL to detect a pre-allocated buffer
and neither allocate nor free the buffer in this case.

> 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).

Given Boot#### contains

    dp1<sep>dp2<sep>dp3<end>

when calling efi_load_image_from_file() three times, once for dp1, dp2,
dp3, each of these device paths can point to a different block device.

Best regards

Heinrich

> 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, unless someone has a better idea.
>
> Thoughts?
>
> Cheers
> /Ilias
>
>
> [...]
>