Re: EFISTUB arguments in Dell BIOS

[Ard Biesheuvel <ardb@kernel.org>]

(adding Peter and Mario)

On Wed, 9 Sep 2020 at 23:38, Arvind Sankar <nivedita@alum.mit.edu> wrote:
>
> On Wed, Sep 09, 2020 at 09:37:02PM +0200, Jacobo Pantoja wrote:
> > > >
> > > > Result saved as image:
> > > > https://ibb.co/vcz48vC
> > > >
> > >
> > > Thanks.
> > >
> > > It looks like the firmware is passing the entire contents of the
> > > Boot0000 variable, rather than just the load options part: I think that
> > > dump will be identical to the output of
> > >
> > >         od -t x2z /sys/firmware/efi/efivars/Boot0000*
> > >
> >
> > It is almost identical. The efivar you mentioned starts with 0x0007 0x0000,
> > and after that, the dump is identical to the one displayed in the debug text
> >
>
> Right, sorry: the first 4 bytes in the sysfs file are the attributes of
> the variable (in this case indicating it is non-volatile, and accessible
> both before and after ExitBootServices). The rest is the actual data.
>
> > >
> > > Ard, do you think we could quirk the conversion to check if the passed
> > > in size was bigger than the parsed command line, and if so check to see
> > > if the bytes 0x7f 0xff 0x0004 (End Device Path) occur somewhere, and
> > > treat the stuff after that as the actual command line?
> >
> > To be honest, if this is an incompliance with UEFI, Dell should fix this.
> > Independently of whether we setup a quirk or not, I'll contact them, in the
> > past I've already got some BIOS bugs fixed (although the process is slow).
> > Obviously I can continue doing whatever testing you may wish.
> >
> > Thank you very much
>
> 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]

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@rani.riverdale.lan/