Arch Linux

sephiroth1395

Member

Registered: 2014-02-17

Posts: 3

EFI Stub problem with arguments

Hello everyone,

I'm currently in the process of getting rid of GRUB through the use of the EFI stub system.  Testing it with a nsh file in OVMF went fine, but it gets hellish with a real computer.  I'm using a Dell Optiplex 7010 with the latest release of the UEFI (A17 I think).
The problem is, this Dhell (pun intended) firmware obviously doesn't support boot arguments for UEFI entries, only a filename to load.  I can get the kernel to start but, well, without its arguments (provided with the -u option of efibootmgr), it obviously won't go far.

Using a shell like tianocore's then loading the nsh script isn't an option as the goal is to make boot fast, transparent and secure (Locked down UEFI, Secure Boot with custom keys, etc.).  I was thinking about creating a small custom EFI application, but I can't seem to get the UDKII tools to work.

So, my question : anyone knows a reliable way of booting using the EFI Stub, preferably without a bootloader, in this configuration ?

pks

Member

From: Germany

Registered: 2012-07-20

Posts: 110

Re: EFI Stub problem with arguments

You can specify command line options when compiling the kernel, see CONFIG_CMDLINE_BOOL and CONFIG_CMDLINE under "Processor type and features". To my knowledge this is the only way to do this.

Strike0

Member

From: Germany

Registered: 2011-09-05

Posts: 1,429

Re: EFI Stub problem with arguments

Have you tried what is mentioned in the bbs post linked to in the wiki? https://wiki.archlinux.org/index.php/EFISTUB

srs5694

Member

From: Woonsocket, RI

Registered: 2012-11-06

Posts: 719

Website

Re: EFI Stub problem with arguments

To the best of  my knowledge, the firmware doesn't know the difference between a filename and anything else as an option to a program (boot loader), so I suspect that you're looking at user error in specifying the options. Since you didn't provide any examples of what you've done, though, I can't be sure of that.

Also and IMHO, launching the kernel directly using the firmware's own boot manager is more hassle than it's worth. It's very limiting and inflexible. If you want to use an EFI stub loader, doing so via rEFInd or gummiboot provides much more flexibility and will be easier to configure. Both can be used with Secure Boot, especially if you want to put your own keys in the NVRAM to replace Microsoft's keys. (Used with Microsoft's keys, gummiboot is incompatible with shim, but can be used with PreLoader -- at least, the last I'd heard. There have been a couple of shim updates since then, and probably multiple gummiboot updates, so this may have changed.)

sephiroth1395

Member

Registered: 2014-02-17

Posts: 3

Re: EFI Stub problem with arguments

Strike0, I tried with -@, to no avail.  Same problem, the kernel doesn't get the options.

Ended up solving it by creating a small UEFI application using gnu-efi.  Flexibility isn't an issue here, and it's intended to boot one and only one kernel for a specific application, with my own keys.  It works with the exact options I tried specifying using efibootmgr, so it clearly appears to be a limitation of the firmware.  Dell's customer service very vague answers lead me to think it's indeed the case.

nstg4

Member

Registered: 2016-05-05

Posts: 1

Re: EFI Stub problem with arguments

I'm dealing with this same issue, I'm using a Latitude XT3 laptop and I've found a way to force the firmware to pass the arguments BUT it is not a solution it just shines a light to the underlying problem: if you set bootnext to a vendor option and then exits THEN the firmware will pass the arguments contained in the the next boot option defined in the boot option list. For example: set bootnext to FFFA (the internal EFI shell) then when you have prompt type exit. the firmware will pass the load options contained in the following boot option. you can use FFFE ("text setup") and since there is no text setup available in my machine it will boot almost immediatly (no shell prompt) into the first entry in the boot option list. vendor boot options are volatile when added to the boot option list in my machine (at least when using efivars with efibootmgr 0.5), only bootnext will work. Current efibootmgr wont list or use vendor boot entries by default, efibootmgr and efivar suck, wish we had a better tools to deal with this, on the other hand it's better than nothing (in my case the default shell profile won't expose bcfg or set_var).

This behavior is not a firmware bug is expected as per UEFI spec: The vendor can set any boot policies they want for normal boot, gentoo handbook says that "UEFI does not pass kernel parameters to the kernel during normal boot" but this is not true, it is not a rule, vendors can opt for it but even UEFI spec mentions that "The NVRAM can also contain load options that are passed directly to the UEFI image" it also mentions that "Much of the behavior of the boot manager is left up to the firmware developer to decide, and details of boot manager implementation are outside the scope of this specification", so is a matter of luck and skills.

damjan

Member

Registered: 2006-05-30

Posts: 452

Re: EFI Stub problem with arguments

What I use on my Thinkpad (and tested in kvm+ovmh) is a combined efi executable with the kernel, initramfs and commandline, all of that signed with my own keys.

I have some notes here:
https://gist.github.com/gdamjan/4a5a30be9a0d8faf1dc7

the tools to make the combined file is objcopy