[PATCH 3/3] efi_loader: setting boot device

[Kyle Evans]

 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
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]]`

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