[PATCH 3/3] efi_loader: setting boot device

[Heinrich Schuchardt]

Am 3. April 2022 23:08:33 MESZ schrieb Kyle Evans <kevans at freebsd.org>:
> On Tue, Jan 12, 2021 at 1:59 PM Heinrich Schuchardt <xypron.glpk at gmx.de> wrote:
>>
>> Up to now the bootefi command used the last file loaded to determine the
>> boot partition. This has led to errors when the fdt had been loaded from
>> another partition after the EFI binary.
>>
>> Before setting the boot device from a loaded file check if it is a PE-COFF
>> image or a FIT image.
>>
>> For a PE-COFF image remember address and size, boot device and path.
>>
>> For a FIT image remember boot device and path.
>>
>> If the PE-COFF image is overwritten by loading another file, forget it.
>>
>> Do not allow to start an image via bootefi which is not the last loaded
>> PE-COFF image.
>>
>
>Hi,
>
>I'm only a little late on this, but may I ask what the rationale of
>this last part is? I'm afraid there are some real-world use cases
>where a compromise would be great, allowing bootefi to accept a random
>region of memory to boot -- in my case, I have the payload (FreeBSD's
>loader.efi) already in memory when U-Boot starts and it's unclear that

Could you, please, describe your use case in some more detail.

Why can't you load loader.efi from the ESP?

>I can come up with some other way to boot it that doesn't involve a
>lot of backflips.
>My specific suggestion, which I can formally post to the list if you
>don't immediately object, is this:
>https://people.freebsd.org/~kevans/uboot.patch
>
>It basically adds another form:
>
>`bootefi addr [fdt [size]]`

What should size be used for?
Both EFI binaries and device-trees provide their size in a header field.

Best regards

Heinrich

>
>If $addr isn't the last loaded PE-COFF, size must be provided. fdt can
>be `-` to signal EFI_FDT_USE_INTERNAL. If we provide an address that
>isn't the last loaded PE-COFF, it wipes out the device path and lets
>efi_run_image() synthesize it. Providing a size with the address of
>the last loaded PE-COFF is an error, but that's a bit arbitrary.
>
>Obviously our loader doesn't get good source disk information this way
>and I have to drive it manually, but that's still orders of magnitude
>better than having to locally shuffle new loader.efis onto a flash
>drive and keep moving the flash drive back and forth to iterate on it.
>
>Thans,
>
>Kyle Evans