Directly use efibootmgr instead of systemd boot
jkufner opened this issue · 6 comments
Sicherboot packs kernel and initrd into single-file EFI executables. Then we can register these EFI executables using efibootmgr without any bootloader and boot them directly. It may not work on every piece of hardware, but it is simpler and it reduces attack surface so Secure Boot should be more reliable.
Would it be possible to add option not to use systemd boot and register kernels directly using efibootmgr? The /boot/EFI directory would be much cleaner (only few kernels in /boot/EFI/debian).
I've tried this using a simple script:
sicherboot build-image "$vmlinuz_file" "$initrd_file" "$target_file" "$target_cmdline_file"
sicherboot sign-image "$target_file"
label="Debian Linux $version (baked & signed)"
efibootmgr | grep "$label" | sed 's/Boot0*\([0-9]\+\)\*\? .*/\1/' | xargs -r -n 1 -- efibootmgr -B -q -b
efibootmgr -c -L "$label" -l "$target_efi"It works quite well, but a biit more robust aproach would be beter.
systemd-boot is more user friendly than booting from efi directly, it allows for overriding cmdline if necessary (when secure boot is disabled). Adding options make things more complicated rather than simpler. To reduce attack surface you may mount efivarfs as read-only (also to avoid bricking your machine during rm -rf / in some cases) and using efibootmgr would make it impossible.
I mean the attack surface during boot (therefore, the efivarfs is not relevant at this time because linux is not running yet). Systemd-boot does not protect configuration files in EFI partition. It does not matter when the Secure Boot is disabled, but when it is enabled, it adds options to the attacker.
It doesn't add any options. Everything loaded by systemd-boot must be signed.
It doesn't add any options. Everything loaded by systemd-boot must be signed.
Commandline arguments can be defined in loader entry files, but I'm not sure it's being used with the current solution. (It's not entirely clear whether the embedded cmdline overrides the loader entry one or vice versa).
I'm always a bit wary of toying with EFI variables directly, and especially adding multiple ones. I barely managed to recover from too many variables once on my X230 - EFI graphics was gone, so there was nothing on the screen until I was within Linux.
Commandline arguments can be defined in loader entry files, but I'm not sure it's being used with the current solution. (It's not entirely clear whether the embedded cmdline overrides the loader entry one or vice versa).
Commandline arguments defined in loader entry files will overwrite embedded cmdline if SecureBoot is disabled and will be ignored if SecureBoot is enabled. That makes them both useful and secure when needed.