Re: [edk2-discuss] Load Option passing. Either bugs or my confusion.

["Laszlo Ersek" <lersek@redhat.com>]

On 04/14/20 02:44, valerij zaporogeci wrote:

> 1. what this pointer (OS Loader
> ImageHandle)->(LOADED_IMAGE_PROTOCOL)->LoadOptions points to?

According to the UEFI spec <https://uefi.org/specifications>, section
"9.1 EFI Loaded Image Protocol":

  LoadOptionsSize  The size in bytes of LoadOptions.
  LoadOptions      A pointer to the image's binary load options.

  [...]

  Each loaded image has an image handle that supports
  EFI_LOADED_IMAGE_PROTOCOL. When an image is started, it is passed the
  image handle for itself. The image can use the handle to obtain its
  relevant image data stored in the EFI_LOADED_IMAGE_PROTOCOL structure,
  such as its load options.

And from section "7.4 Image Services", near the LoadImage() boot
service:

  Once the image is loaded, firmware creates and returns an EFI_HANDLE
  that identifies the image and supports EFI_LOADED_IMAGE_PROTOCOL and
  the EFI_LOADED_IMAGE_DEVICE_PATH_PROTOCOL. The caller may fill in the
  image's "load options" data, or add additional protocol support to the
  handle.

So an agent calls the LoadImage() boot service to load the image. Then
it looks up the EFI_LOADED_IMAGE_PROTOCOL instance on the handle that
was output by LoadImage(). The agent populates LoadOptionsSize and
LoadOptions in said EFI_LOADED_IMAGE_PROTOCOL instance, and then calls
StartImage(). The started image can then consume LoadOptionsSize and
LoadOptions.

I think you mistook these fields for describing an EFI_LOAD_OPTION
structure (from section "3.1.3 Load Options"). EFI_LOAD_OPTION is a
different thing -- the EFI_LOADED_IMAGE_PROTOCOL.LoadOptions field
points to a binary blob whose interpretation is specific to the image
being started. Its internals are not regulated by the spec.

More below:

>
> if it points to the Load Option Descriptor, then on OVMF it doesn't,
> since it points to only OptionalData[].
> if it was meant to point to OptionalData[], then:
>
> 1. how does an OS Loader get _its_ Load Option FilePathList[]? ALL
> elements.
> and

Again, EFI_LOADED_IMAGE_PROTOCOL.LoadOptions does not point to an
EFI_LOAD_OPTION structure.

Still, your question #1 makes sense; indeed an OS boot loader (or
another UEFI app) is "entitled" to see the UEFI device path from which
it was loaded from. The passage I quoted above already mentions
EFI_LOADED_IMAGE_DEVICE_PATH_PROTOCOL. It is specified in detail in
section "9.2 EFI Loaded Image Device Path Protocol". Excerpt:

  The Loaded Image Device Path Protocol must be installed onto the image
  handle of a PE/COFF image loaded through the EFI Boot Service
  LoadImage(). A copy of the device path specified by the DevicePath
  parameter to the EFI Boot Service LoadImage() is made before it is
  installed onto the image handle. It is legal to call LoadImage() for a
  buffer in memory with a NULL DevicePath parameter. In this case, the
  Loaded Image Device Path Protocol is installed with a NULL interface
  pointer.

Summary:

- Passing arguments to a UEFI image: locate EFI_LOADED_IMAGE_PROTOCOL on
the image handle, and populate the LoadOptions / LoadOptionsSize
members. The "arguments" are a binary blob, only defined by the
receiving application.

- Finding where a UEFI image was loaded from: locate
EFI_LOADED_IMAGE_DEVICE_PATH_PROTOCOL on the image handle.

- Regarding "EFI_LOAD_OPTION.OptionalData": in case you boot a Boot####
option, it is "EFI_LOAD_OPTION.OptionalData" that will be passed to the
image in "EFI_LOADED_IMAGE_PROTOCOL.LoadOptions".

More below:

> 2. should FilePathList[] be a multiinstance Device Path (ending with
> type 7F, subtype 1, except the last), or every element should end with
> {7F, FF}?

I cannot answer this. The spec writes, about "FilePathList":

  A packed array of UEFI device paths. The first element of the array is
  a device path that describes the device and location of the Image for
  this load option. The FilePathList[0] is specific to the device type.
  Other device paths may optionally exist in the FilePathList, but their
  usage is OSV specific. Each element in the array is variable length,
  and ends at the device path end structure. Because the size of
  Description is arbitrary, this data structure is not guaranteed to be
  aligned on a natural boundary. This data structure may have to be
  copied to an aligned natural boundary before it is used.

I'm not sure if the "non-first" elements in this array are supposed to
be 2nd and later devpath instances in a single multi-instance device
path, or if they are entirely separate (themselves single or
multi-instance) device paths.

Either way, I don't think those "elements" are passed to the loaded
image in any direct way. You could perhaps get back at the
EFI_LOAD_OPTION once the loaded image is running with the help of the
"BootCurrent" standard UEFI variable.

Thanks
Laszlo