Load Option passing. Either bugs or my confusion.

valerij zaporogeci

Hello. Do I understand correctly, that LoadOptions field of the LOADED_IMAGE_PROTOCOL instance of an OS loader image, points to the Load Option descriptor, the format of which is described in the Boot Manager section of the spec? If yes, then I faced a behavior, that looks like bugs. It's on OVMF x64 (qemu) (and arm64 too, but only from the UEFI shell, since "ramfb" device shows broken view of what Boot Manager draws, that makes it unusable).
1) when I start my OSL from the UEFI shell, the LoadOptions field is not NULL, but the "load option" referenced, has only Description field valid, Attributes field doesn't seem valid, it contains 0x00730066. Most importantly, - FilePathListLength field is set to a nonzero value (48), but, - there is no valid FilePathList[] Device Path array after the Decsription field. Scanning memory there, reveals all zeros. Isn't it a bug?
2) when I create a Load Option in the Boot Manager, pointing to the same OSL and don't add "optional data" during the creation, the LoadOptions field is NULL. Why? How my OSL is supposed to get FilePathList[] then? For distinction between preinstallation run and postinstallation one, the OSL relies on the presence or absence of the Load Option or if there is one, - on the presence or absence FilePathList[1] Device Path, which points to the OS boot volume for postinstallation or is absent otherwise. But I cannot find FilePathList at all.
3) If I create a Load Option as in 2), but with "optional data", LoadOptions is not NULL, those "optional data" turn to be a "Description" field of the Load Option descriptor reported, and still, there is no FilePathList.
In all the above cases, where LoadOptions is not NULL, LoadOptionsSize equals exactly sizeof(Attributes) + sizeof(FilePathListLength) + sizeof(Description) + 2. the latter is NULL CHAR16. there is no FilePathList. Still FilePathListLength field reports some values.

Is it normal or it's bugs? Plus, there is yet one wierdness: DeviceHandle field (of the same LOADED_IMAGE_PROTOCOL instance for the OSL), which is a device handle (hard drive in this case - Type 4, Subtype - 1), doesn't have EFI_DEVICE_PATH_TO_TEXT_PROTOCOL instance on itself. but shouldn't it have it?

The main question is why there is no FilePathList[] part of the Load Option passed to the OSL in any scenario of its launch? It should be there at least for the case of the Load Option, created via the Boot Manager menu, right?

Join discuss@edk2.groups.io to automatically receive all group messages.