Skip to content
This repository has been archived by the owner on Jan 20, 2023. It is now read-only.

Sign the default/fallback loader #3

Open
wants to merge 2 commits into
base: main
Choose a base branch
from

Conversation

darander
Copy link

@darander darander commented Feb 3, 2017

Apart from installing systemd-boot at /EFI/systemd/, bootctl also installs a
default/fallback loader at /EFI/BOOT/BOOT
.EFI. Sign this loader too.

@darander
Copy link
Author

darander commented Feb 3, 2017

I've got no idea what check has failed, unless it's caused by the dependency on tr...

@julian-klode
Copy link
Owner

julian-klode commented Feb 3, 2017

Well, cp: cannot stat '/root/src/github.com/julian-klode/sicherboot/tests/tmp/efi/EFI/BOOT/BOOTX64.EFI': No such file or directory

-> the mock bootctl does not install a bootx64.efi.

WRT signing that: It's not that easy. The default might not be a systemd-boot bootloader. Imagine the default is the windows loader, for example - we surely don't want to add a signature after each bootctl command. We could probably just cmp the default bootloader against the other one?

Then there's the case issue: I think systemd-boot is reasonably safe, but the default bootloader and path to it may have all kinds of weird casing. And if the ESP is mounted as utf-8, that leads to errors. So we probably have to try something fancy there like EFI/[Bb][Oo][Oo][Tt]/[Bb][Oo][Oo][Tt] (and the same for the architecture) - maybe we should also do [Ee][Ff][Ii] everywhere?. I did get bitten by this when I packed gummiboot.

Apart from that, there's only a minor style issue: Don't use ... - use modern $(...) instead, it's much more readable.

@darander
Copy link
Author

darander commented Feb 3, 2017

Hm, you're right... I've only ever tried to use UEFI Secure Boot on my own debian laptop...
(Why make things easy and standardize on paths and file names...)

No, I don't want to add a signature on all EFI-binaries, only the one that bootctl update has installed.
The reason is that although I've got systemd-boot prior to the fallback loader in my efi configuration, I'm always getting error that the signature check fails when I'm rebooting my laptop after a systemd-update. I've tracked the issue down to being that the default/fallback loader hasn't been signed, after that bootctl update updated it.

In other words, we would need to find a way for bootctl to tell us which EFI-binaries it has installed (with their path's). That would make it robust. Though, parsing the output of bootctl is not something I'd like to do...

I'll have to think a bit more about how to approach this.

Feel free to close the pull-request.

Cheers,
Anders

Instead of hardcoding the installation path of the systemd-boot, to be
used to sign it, try to extract the actual path's that bootctl installs
systemd-boot to. Usually, it's also installing a fallback loader.

Signed-off-by: Anders Darander <anders.darander@gmail.com>
@darander
Copy link
Author

I've again grown tired of having my computer fail to find a signature on the fallback loader after each systemd update. Thus, I'm making a second attempt at this.

As I'm not aware of any good command to bootctl to ask it for which path's it'll use to install systemd-boot, I've instead opted to parse the output of the actual install process. Let's see how that works with the mock bootctl...

The bootctl command in sicherboot was rewritten to parse the output
of the systemd bootctl command. Add the relevant output to the mock.

Signed-off-by: Anders Darander <anders.darander@gmail.com>
@julian-klode
Copy link
Owner

I wonder why you don't set a boot order using efibootmgr that uses the non-default bootloader. For example, my system is configured to directly use systemd-boot by placing its entry first in the line.

BootCurrent: 0017
Timeout: 0 seconds
BootOrder: 0017,0000,0001,0002,0003,0018,0007,0008,0009,000C,000A,000B,000D,000E,000F,0010,0011,0012
Boot0000  Setup
Boot0001  Boot Menu
[...]
Boot0017* Linux Boot Manager
Boot0018* debian
Boot0019* PCI LAN

@darander
Copy link
Author

Yes, that's another option for sure. However, I'd still prefer to have all loaders installed by bootctl signed.

Though, feel free to close the issue...

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants