stub doesn't load properly from non-secure boot

[Adam Schaefers]

I have run across an interesting issue,

Where the stub generated from sbupdate loads from shim-->refind-->stub-->linux perfectly normal when using secure boot. But when reverting to non-secure boot, however, I am unable to get the stub to load up linux properly via refind, and it crashes to an emergency shell.

note: I am able to load the linux kernel directly and pass the correct parameters from refind in non-secure mode, and all will load as normal. It appears only when loading from the stub in non-secure boot to be the issue.

How do I go about debugging this? Any ideas what may be the cause?

Thanks.

[Andrey Vihrov]

Hi,

It is difficult to say without more information. I have one setup which works in non-SB mode (but it boots the image directly from firmware).

You can check if bypassing the loader chain and booting directly from firmware in non-SB mode works. You can also load an EFI shell, boot the image from there and see if any errors are shown.

If the above works, you could contact the rEFInd author for assistance.

[Adam Schaefers]

I agree, this may not be a problem with sbupdate, and could be a refind issue. I will report back with more information as soon as I have any. I have emailed the refind author as well to see if he may have any ideas about this. As well as I have posted on the Arch forums. No replies from either as of this time, you're the first to reply!

Thanks for making sbupdate, I really love the way it generates the stubs and signs everything for me instead of using pacman hooks.

[ansemjo]

This is actually a 'problem' of the EFI stub.

See this comment and this section from stub.c:

/* if we are not in secure boot mode, accept a custom command line and replace the built-in one */
if (!secure && loaded_image->LoadOptionsSize > 0) {
        CHAR16 *options;
        CHAR8 *line;
        UINTN i;
        options = (CHAR16 *)loaded_image->LoadOptions;
        cmdline_len = (loaded_image->LoadOptionsSize / sizeof(CHAR16)) * sizeof(CHAR8);
        line = AllocatePool(cmdline_len);
        for (i = 0; i < cmdline_len; i++)
                line[i] = options[i];
        cmdline = line;

I myself tried to be clever and boot the bundled and signed stub from an EFI shell before activating Secure Boot .. even though I did not specify any options in the shell, I guess I hit that exact same problem where the bundled cmdline simply gets replaced.

If anything, this is a bug with systemd's stub because it mistakenly overwrites options, despite none being specified.

I fixed that by specifying an entry with efibootmgr directly, which had no options. I.e.:
efibootmgr --create --label 'Linux' --loader 'linux-signed.efi' .. where the executable is at $ESP/linux-signed.efi.

I'd suggest adding a small section in the readme?

[Andrey Vihrov]

Thanks for the investigation. I can add a note in the readme at the bootloaders section.

I probably see where the problem is coming from, the EFI shell works with "command lines" and not separate image name/options, just like a regular shell. So not specifying any options results in an empty argument list being passed.

You could open an issue at systemd/systemd and see what they have to say.

[Andrey Vihrov]

There is now a warning in the readme about this. I hope it is noticeable enough.

As explained in #4 (comment), the issue is with the systemd EFI stub, so it is up to systemd/systemd to decide on correct behavior.