[PATCH v2 4/6] efi_loader: support boot from URI device path
Masahisa Kojima
masahisa.kojima at linaro.org
Fri Sep 15 09:45:57 CEST 2023
On Fri, 15 Sept 2023 at 15:32, Ilias Apalodimas
<ilias.apalodimas at linaro.org> wrote:
>
> Hi Kojima-san,
>
> > > > + efi_handle_t *image_handle)
> > > > +{
> > > > + efi_status_t ret;
> > > > + efi_handle_t bm_handle;
> > > > + struct efi_handler *handler;
> > > > + struct efi_device_path *file_path;
> > > > + struct efi_device_path *device_path;
> > > > +
> > > > + if (dev_tag_get_ptr(dev, DM_TAG_EFI, (void **)&bm_handle)) {
> > > > + log_warning("DM_TAG_EFI not found\n");
> > > > + return EFI_INVALID_PARAMETER;
> > > > + }
> > > > +
> > > > + ret = efi_search_protocol(bm_handle,
> > > > + &efi_simple_file_system_protocol_guid, &handler);
> > > > + if (ret != EFI_SUCCESS)
> > > > + return ret;
> > > > +
> > > > + ret = efi_search_protocol(bm_handle, &efi_guid_device_path, &handler);
> > > > + if (ret != EFI_SUCCESS)
> > > > + return ret;
> > > > +
> > > > + ret = efi_protocol_open(handler, (void **)&device_path, efi_root, NULL,
> > > > + EFI_OPEN_PROTOCOL_GET_PROTOCOL);
> > > > + if (ret != EFI_SUCCESS)
> > > > + return ret;
> > > > +
> > > > + file_path = expand_media_path(device_path);
> > > > + ret = EFI_CALL(efi_load_image(true, efi_root, file_path, NULL, 0,
> > > > + image_handle));
> > > > +
> > > > + efi_free_pool(file_path);
> > > > +
> > > > + return ret;
> > > > +}
> > >
> > > We need to decide what we want here. There were recently some patches from
> > > Raymond [0] which piggybacked on your earlier eficonfig work. I think the
> > > last patch of this series hasn't been merged due to a test failing, but we
> > > should fix it.
> > > That patch has a different approach. Everytime a disk appears it will add
> > > a boot option if the default filepath is found and that's how we fixed the
> >
> > efi_bootmgr_update_media_device_boot_option() automatically adds the
> > boot option if the device handle installed EFI_SIMPLE_FILE_SYSTEM_PROTOCOL,
> > but it does not check whether the default file path is found or not.
> > When the user selects the automatically created boot option,
> > expand_media_path()
> > is called and efibootmgr tries to boot with the default file.
> >
>
> Ah correct. On the function above though, we are we open coding a
> different version of efi_open_protocol()? Can't we call that instead of
> efi_search_protocol()/efi_protocol_open()?
I will call efi_open_protocol() instead. Thanks.
>
> > > behaviour of efibootmgr to adhere to the EFI spec. This patch is doing the
> > > opposite, trying to detect the BOOTAA64.EFI etc on the fly. I think I
> > > prefer the approach you have here, but we should end up with one solution
> > > to solve both.
> >
> > This HTTP Boot case is slightly different from the case where the user selects
> > the automatically added boot option.
> > In this case, user selects the URI device path boot option. The
> > efibootmgr downloads the
> > file, mount the image, and try to boot with the default file name on the fly.
> > When the patch[0] is merged, it is possible to boot the downloaded iso
> > image from the
> > automatically added "blkmap" boot option, but I think efibootmgr needs
> > to boot with
> > the URI device path user selected that this series does, not boot
> > from the "blkmap" boot option.
> >
>
> Indeed, the used must still select the 'http://' boot option.
> It's been a while and I don't remember the eficonfig details. Do you
> remember why we decided to store the load options after scanning back then?
We just followed the EDK2 reference implementation.
> IOW if we pick this up, can we also use it on the efibootmgr code and scan
> all disks on the fly instead of adding boot options?
Yes, it is possible, but I'm not sure scanning all the disks on the fly
is a good idea. For users, it is hard to control which device is selected
to boot.
Now come to think of it, we add the one load option for each disk when the
disk is detected, then try to boot with the default file by scanning
the default boot file
in the selected disk.
In current implementation, the following load options are automatically created.
Boot0000:
attributes: A-- (0x00000001)
label: virtio 0:1
file_path: /HD(1,GPT,b6b38698-f211-4d78-b208-f68e5523e588,0x800,0x100000)
data:
00000000: c1 ac c1 38 c0 9f f0 41 b9 01 fa 74 d6 d6 e4 de ...8...A...t....
Boot0001:
attributes: A-- (0x00000001)
label: virtio 0:2
file_path: /HD(2,GPT,98533ff2-11d5-428c-b323-9afaf6b4abd8,0x100800,0x1122000)
data:
00000000: c1 ac c1 38 c0 9f f0 41 b9 01 fa 74 d6 d6 e4 de ...8...A...t....
For this disk, only the block device "virtio 0" load option is enough,
we can search
for the default boot file on the fly. This is what EDK2 does.
Thanks,
Masahisa Kojima
>
> > >
> > > > +
> > > > +/**
> > > > + * load_default_file_from_blk_dev() - load the default file
> > > > + *
> > > > + * @blk pointer to the UCLASS_BLK udevice
> > > > + * @handle: pointer to handle for newly installed image
> > > > + * Return: status code
> > > > + */
> > > > +static efi_status_t load_default_file_from_blk_dev(struct udevice *blk,
> > > > + efi_handle_t *handle)
> > > > +{
> > > > + efi_status_t ret;
> > > > + struct udevice *partition;
> > > > +
> > > > + /* image that has no partition table but a file system */
> > > > + ret = try_load_default_file(blk, handle);
> > > > + if (ret == EFI_SUCCESS)
> > > > + return ret;
> > > > +
> > > > + /* try the partitions */
> > > > + device_foreach_child(partition, blk) {
> > > > + enum uclass_id id;
> > > > +
> > > > + id = device_get_uclass_id(partition);
> > > > + if (id != UCLASS_PARTITION)
> > > > + continue;
> > > > +
> > > > + ret = try_load_default_file(partition, handle);
> > > > + if (ret == EFI_SUCCESS)
> > > > + return ret;
> > > > + }
> > > > +
> > > > + return EFI_NOT_FOUND;
> > > > +}
> > > > +
> > > > +/**
> > > > + * try_load_from_uri_path() - Handle the URI device path
> > > > + *
> > > > + * @uridp: uri device path
> > > > + * @lo_label label of load option
> > > > + * @handle: pointer to handle for newly installed image
> > > > + * Return: status code
> > > > + */
> > > > +static efi_status_t try_load_from_uri_path(struct efi_device_path_uri *uridp,
> > > > + u16 *lo_label,
> > > > + efi_handle_t *handle)
> > > > +{
> > > > + char *s;
> > > > + int uri_len;
> > > > + int image_size;
> > > > + efi_status_t ret;
> > > > + ulong image_addr;
> > > > +
> > > > + s = env_get("loadaddr");
> > > > + if (!s) {
> > > > + log_err("Error: loadaddr is not set\n");
> > > > + return EFI_INVALID_PARAMETER;
> > > > + }
> > > > + image_addr = hextoul(s, NULL);
> > > > + image_size = wget_with_dns(image_addr, uridp->uri);
> > > > + if (image_size < 0)
> > > > + return EFI_INVALID_PARAMETER;
> > > > +
> > > > + /*
> > > > + * If the file extension is ".iso" or ".img", mount it and try to load
> > > > + * the default file.
> > >
> > > Don't we have a better way to validate isos and efi apps instead of
> > > the extension? The efi is checked against a valid PE/COFF image so I guess
> > > we'll really on the mount to fail for isos?
> >
> > EDK2 reference implementation checks the file type with the following priority.
> > 1) "Content-Type" header in HTTP response message
> > 2) Filename Extensions
> > Documentation is here[1].
> >
> > Since "Content-Type" is not available in the current U-Boot wget, file extension
> > is used to identify ISO images.
>
> Ok fair enough, we can go back and improve this once lwip is merged I guess
>
> >
> > [1] https://github.com/tianocore/tianocore.github.io/wiki/HTTP-Boot#ram-disk-boot-from-http
> >
>
> [...]
>
> Thanks
> /Ilias
More information about the U-Boot
mailing list