> > > > Ok, this is laid out in section 3.1 of the spec which defines the format > > of the EFI_LOAD_OPTION descriptor. Dell's BIOS is passing the entire > > descriptor instead of just the OptionalData part. > > > > OptionalData The remaining bytes in the load option descriptor are a > > binary data buffer that is passed to the loaded image. > > If the field is zero bytes long, a Null pointer is > > passed to the loaded image. The number of bytes in > > OptionalData can be computed by subtracting the starting > > offset of OptionalData from total size in bytes of the > > EFI_LOAD_OPTION. > > > > https://uefi.org/sites/default/files/resources/UEFI_Spec_2_8_final.pdf > > > > This vaguely rings a bell so I have cc'ed some folks who may have run > into this in the past. Complete thread can be found at [0] > Thanks for sharing the context. This rings a bell for me with the last time I recall worrying about the Load Options and this commit in shim comes to mind: https://github.com/rhboot/shim/commit/3322257e611e2000f79726d295bb4845bbe449e7 It seems to me the shim approach to the problem isn't too big of a deal: count the number of strings and if it's greater or equal to 2, then throw out the first one. It's also already been used in production code across a ton of platforms for several years, so if there was major breakages I would expect they're covered in that code too by now. > The firmware is obviously passing the wrong data, and I am reluctant > to quirk this out, since we'd have to interpret the contents of these > UEFI variables, and given the amount of 'value add' by the BIOS > vendors in this area, we may end up breaking things on other > platforms. > > [0] https://lore.kernel.org/linux- > efi/20200909203830.GA490605@xxxxxxxxxxxxxxxxxx/ In the defense of others who have interpreted the spec, as I'm reading it I'm not convinced that it explicitly calls out what data should be passed. In section 7.4 which explains how LoadImage() behaves. ``` 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 ``` In this context the caller is most likely BDS, and it's "optional" to load content in. Within section 9.1 which describes the loaded image protocol the exact format of the content of "LoadOptions" is not described. I can see an interpretation it should be the full descriptor or that it can be the OptionalData. And actually if you looks in history from EDK code, you can see that it's been done that way there too at least at one time: https://github.com/tianocore/edk2/blob/b8d06293caa122f9c3bd2ae32a6c3f790a054e03/IntelFrameworkModulePkg/Library/GenericBdsLib/BdsBoot.c#L2433 Jacobo, Can you provide some more details on your system that is reproducing this? Model number, FW version would be useful. The links provided earlier on are on pretty old stuff, so knowing that this is a problem on something more current would be good. I guess the other option if Ard chooses not to adopt a quirk for this described behavior is to use shim to load the kernel efistub, and let it do the split for you.
