Re: EFISTUB arguments in Dell BIOS

[Arvind Sankar <nivedita@alum.mit.edu>]

On Wed, Sep 09, 2020 at 07:34:59PM +0200, Jacobo Pantoja wrote:
> On Wed, 9 Sep 2020 at 00:32, Arvind Sankar <nivedita@alum.mit.edu> wrote:
> >
> > On Wed, Sep 09, 2020 at 12:12:35AM +0200, Jacobo Pantoja wrote:
> > > >
> > > > Just to check, are you directly booting from firmware into the EFI stub,
> > > > or do you have something (grub2/systemd-boot/refind etc) in between?
> > > > Which kernel version are you using, and are you able to compile your own
> > > > kernel with patches for testing? If so, we should be able to add in some
> > > > debug statements in the EFI stub itself to see what the firmware passed
> > > > it as the command line, and if it's getting truncated or something.
> > > >
> > > Yes I'm booting directly from firmware into EFI stub, no
> > > grub2/systemd-boot/refind
> > > involved. My current kernel is 5.8.5.
> > > I'm able to compile kernel with patches, no problem.
> > > As a side note, the exact same kernel with the exact same efibootmgr command
> > > is booting in other machines (different models).
> >
> > Great. Can you test the patch below? It should dump the options passed
> > to the EFI stub, before/after converting from UTF-16 to UTF-8, and then
> > wait for a key. If you can take a picture of the screen it should show
> > what's going on, hopefully.
> 
> 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*

The start of it is structured data with some attributes, the label, and
the path to the linux image, and all this is then followed by the actual
load options. The EFI stub conversion routine assumes only the load
options will get passed to it (that's what the UEFI spec states), and so
treats the first two words (0x0001 0x0000) as forming a complete string
for the command line when converting. The initrd= processing on the
other hand is pretty rudimentary and just scans the entire load options
for initrd=, and so happens to work.

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?