Bugs when starting an UEFI application from the shell. OVMF, UEFI shell.

Bugs when starting an UEFI application from the shell. OVMF, UEFI shell.

[vlrzprgts]

Hi. when starting an OS Loader, from the UEFI shell,
the LoadOptions field of the Loaded Image Protocol instance for the
loader image is not NULL, unlike the case of booting it through the
Boot Manager's "boot from file" option. This "load option" contains:
1) invalid value in the Attributes field, some random value - 0x00730066
2) invalid value in the FilePathListLength field, it's non zero (48)
however, there is no valid device path associated, see below.
the only valid field is Description, consisting of the file path
string for the launched loader, starting with colon ":", like this
":\efi\path\to\loader\osl.efi"
there is no any device path after that, supposedly FilePathList[].
Trying to feed this "path" to the ConvertDevicePathToText() hangs the
machine (it's on OVMF on qemu x64). Not even NULL is returned, just a
hang.
the size of this "load option", reported by the LoadOptionsSize,
corresponds to the first two fields' length, plus the Description
string length, with NULL CHAR16 incl.
sizeof(Attributes) + sizeof(FilePathListLength) + sizeof(Description) + 2
Also, DeviceHandle field of the Loaded Image Protocol instance,
doesn't support EFI_DEVICE_PATH_TO_TEXT_PROTOCOL. Why? Isn't is a
"device handle"?

Are these bugs or I am wrong?
1) If the shell really needs to pass this "load option", then
shouldn't it set FilePathListLength to 0? since there is no device
path associated? and set Attributes to something valid?
2) Or, maybe, LoadOptions field of the Loaded Image
protocol instance should be set to NULL? that is, - straight reporting
absence of a load option, which is really the case. just like the boot
manager does, when loads the file from "boot from file", instead of
the real Load Option chosen.

this fake load option has only file path string, which already is
known through the FilePath field of the Loaded Image Protocol
instance, but it has potential of breaking the OSL logic, or
worse - just hanging it with those invalid field values. the OSL
relies on the presence/absence of a real load option for distinction
between preinstallation run (live mode) and postinstallation.