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;
}
next prev parent 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