[PATCH 3/3] efi_loader: setting boot device

[Kyle Evans]

On Mon, Apr 4, 2022 at 12:09 AM Heinrich Schuchardt <xypron.glpk at gmx.de> wrote:
>
> 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'm explicitly trying to override the loader.efi from ESP, because
it's broken and I can't (easily) keep switching it out. This is on
Apple's M1, so I can happily inject the new loader.efi from m1n1 (much
like the JTAG use-case mentioned in this file) for testing new
iterations.

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

Right now it's used because efi_run_image() wants the buffer size to
construct the memory-based device path. I'm not familiar enough with
U-Boot to know if there's a sensible API for grabbing the size from
this PE image in memory.