Linux EFI development
 help / color / mirror / Atom feed
From: Arvind Sankar <nivedita@alum.mit.edu>
To: Jacobo Pantoja <jacobopantoja@gmail.com>
Cc: Arvind Sankar <nivedita@alum.mit.edu>,
	ardb@kernel.org, linux-efi@vger.kernel.org
Subject: Re: EFISTUB arguments in Dell BIOS
Date: Tue, 8 Sep 2020 18:32:55 -0400	[thread overview]
Message-ID: <20200908223255.GA276578@rani.riverdale.lan> (raw)
In-Reply-To: <CAO18KQg9wLFF8KxZdP4fVv-vk_CpfV+_v38WnCJ-uqEAJ3FNwA@mail.gmail.com>

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.

> >
> > If you boot directly from firmware, the EFI stub is what would load the
> > initramfs, and at least the initrd= argument should be in /proc/cmdline
> > after boot.
> >
> That is weird; I can see the difference between including initrd arg or not
> including, but "cat /proc/cmdline" returns a blank line. Hexdump reveals
> that it is really 0x01 0x0a. I'm 100% sure the initramfs is being loaded when
> passed as an argument, although the cmdline does not reflect it.

The 0x0a I think is added by /proc/cmdline, so the cmdline is just 0x01.
The only thing I can think of is that the conversion from UTF-16 to
UTF-8 in the EFI stub went wrong somehow: the initrd= argument is
processed directly from the UTF-16 cmdline, but the UTF-8 converted
version is what is passed to the kernel.

> Yes, I'm including here my efibootmgr command, and the output after calling
> with -v. Line breaks are simply for the email readability.
> 
> $ efibootmgr --disk /dev/disk/by-id/ata-(...) --part 1 --create
> --label "ArchLinux" \
>   --loader /vmlinuz-linux --unicode "root=LABEL=ArchRoot rw quiet \
>   initrd=\intel-ucode.img initrd=\initramfs-linux.img intel_iommu=on audit=0"
> 
> $ efibootmgr -v
> Boot0000* ArchLinux
> HD(1,GPT,b0fd4cf1-1566-4c71-b214-c3c0c5924fea,0x800,0xfa000)/File(\vmlinuz-linux)r.o.o.t.=.L.A.B.E.L.=.A.r.c.h.R.o.o.t.
> .r.w. .q.u.i.e.t. .i.n.i.t.r.d.=.\.i.n.t.e.l.-.u.c.o.d.e...i.m.g.
> .i.n.i.t.r.d.=.\.i.n.i.t.r.a.m.f.s.-.l.i.n.u.x...i.m.g.
> .i.n.t.e.l._.i.o.m.m.u.=.o.n. .a.u.d.i.t.=.0.
> 
> I've just checked right after a power cycle, with the exact same result:
> 1) No parameters appended in efibootmgr => black screen
> 2) Parameters appended in efibootmgr => boots to rescue shell
> 

diff --git a/drivers/firmware/efi/libstub/efi-stub-helper.c b/drivers/firmware/efi/libstub/efi-stub-helper.c
index f735db55adc0..084cf4812a02 100644
--- a/drivers/firmware/efi/libstub/efi-stub-helper.c
+++ b/drivers/firmware/efi/libstub/efi-stub-helper.c
@@ -252,6 +252,11 @@ char *efi_convert_cmdline(efi_loaded_image_t *image, int *cmd_line_len)
 	int options_bytes = 0, safe_options_bytes = 0;  /* UTF-8 bytes */
 	bool in_quote = false;
 	efi_status_t status;
+	const char *cmdline;
+	size_t i;
+	efi_input_key_t key;
+
+	efi_info("Load options: %08x @ %p\n", efi_table_attr(image, load_options_size), options);
 
 	if (options) {
 		s2 = options;
@@ -313,6 +318,41 @@ char *efi_convert_cmdline(efi_loaded_image_t *image, int *cmd_line_len)
 	snprintf((char *)cmdline_addr, options_bytes, "%.*ls",
 		 options_bytes - 1, options);
 
+	efi_info("%.*ls\n", options_bytes - 1, options);
+	/* Hex dump */
+	efi_info("UTF-16:\n");
+	options_chars = efi_table_attr(image, load_options_size)/2;
+	i = 0;
+	do {
+		size_t j;
+		efi_info("%p: ", options + i);
+		for (j = i; j < options_chars && j < i + 8; j++)
+			efi_printk("%04x ", options[j]);
+		for (; j < i + 8; j++)
+			efi_printk("%4c ", ' ');
+		for (j = i; j < options_chars && j < i + 8; j++)
+			efi_printk("%lc", options[j]);
+		efi_printk("\n");
+		i += 8;
+	} while (i < options_chars);
+	efi_info("UTF-8:\n");
+	cmdline = (const char *)cmdline_addr;
+	i = 0;
+	do {
+		size_t j;
+		efi_info("%p: ", cmdline + i);
+		for (j = i; j < options_bytes && j < i + 8; j++)
+			efi_printk("%02x ", cmdline[j]);
+		for (; j < i + 8; j++)
+			efi_printk("%2c ", ' ');
+		for (j = i; j < options_bytes && j < i + 8; j++)
+			efi_printk("%c", cmdline[j]);
+		efi_printk("\n");
+		i += 8;
+	} while (i < options_bytes);
+
+	efi_wait_for_key(120 * 1000000, &key);
+
 	*cmd_line_len = options_bytes;
 	return (char *)cmdline_addr;
 }

  reply	other threads:[~2020-09-08 22:33 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <CAO18KQgxfCBFacLxpLZJZ6iDmEA83DUwG2kjfPyJmPZHPQZ5vQ@mail.gmail.com>
2020-09-07 17:00 ` EFISTUB arguments in Dell BIOS Arvind Sankar
2020-09-08 22:12   ` Jacobo Pantoja
2020-09-08 22:32     ` Arvind Sankar [this message]
2020-09-09 17:34       ` Jacobo Pantoja
2020-09-09 19:00         ` Arvind Sankar
2020-09-09 19:37           ` Jacobo Pantoja
2020-09-09 20:38             ` Arvind Sankar
2020-09-10 10:11               ` Ard Biesheuvel
2020-09-10 20:40                 ` Limonciello, Mario
2020-09-11  0:04                   ` Arvind Sankar
2020-09-11  5:53                     ` Jacobo Pantoja
2020-09-11 15:28                       ` Limonciello, Mario
2020-09-12 17:51                         ` [RFC PATCH 0/2] Quirk to handle " Arvind Sankar
2020-09-12 17:51                           ` [RFC PATCH 1/2] efi/x86: Add a quirk to support command line arguments on Dell EFI firmware Arvind Sankar
2020-09-14 16:56                             ` Limonciello, Mario
2020-09-14 18:30                               ` Ard Biesheuvel
2020-09-14 18:45                                 ` Limonciello, Mario
2020-09-12 17:51                           ` [RFC PATCH 2/2] efi/libstub: Dump command line before/after conversion Arvind Sankar
2020-09-14 15:59                           ` [RFC PATCH 0/2] Quirk to handle Dell BIOS Jacobo Pantoja

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20200908223255.GA276578@rani.riverdale.lan \
    --to=nivedita@alum.mit.edu \
    --cc=ardb@kernel.org \
    --cc=jacobopantoja@gmail.com \
    --cc=linux-efi@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox