GRUB2 EFI Support In Fedora 31 Likely To Include New Security Modules

[starshipeleven]

Well if you boot multiple OS, then Grub is invaluable. if it's just the one, then yes alternatives like systemd-boot and refind are a good idea.

Edit: GRUB is also pretty useful if your system gets screwed up, and you need to change command line parameters to atleast boot to the command line and fix it.

Sorry but I have to stop you right there good sir.
rEFInd is VERY good at dealing with multiboot environments as it scans all kernels/OS/bootloaders on boot so it will autodetect everything without any mainteneance on your side.
It also allows you to edit the command line parameters (actually allows you to set up multiple sets of them in a config textfile beforehand so you can just choose another profile if you don't want to type).

It also has menu for EFI tools like memtest and EFI shell (that you need to provide and drop in the appropriate folder), and can reboot to UEFI firmware (as long as the UEFI allows this at all).

It also detects automatically the secure boot management tool things a distro installs in the EFI partition so you can also invoke them on boot to do key management.

GRUB can do all this only with extensive configuration that has to be updated manually on any kernel/OS/bootloader change.


What GRUB can do which rEFInd can't do is actually access LVM or RAID (* with metadata=0.9 it can access it but your array size is now limited to 2TB) or encrypted partitions to boot your kernel.

[starshipeleven]

If so, how is systemd-boot supposed to boot from a LUKS-encrypted boot partition?

By keeping the kernel in the EFI partition I guess. You want to be using Secure Boot in any case if you are serious about that.

Only way it could boot directly is if someone wrote a EFI driver for LUKS encryption (or ZFS). Afaik the only project providing EFI drivers (besides the ones shipped with rEFInd project) is https://efi.akeo.ie/ which is using GRUB's EFI filesystem support modules.

[Britoid]

By keeping the kernel in the EFI partition I guess. You want to be using Secure Boot in any case if you are serious about that.

Only way it could boot directly is if someone wrote a EFI driver for LUKS encryption (or ZFS). Afaik the only project providing EFI drivers (besides the ones shipped with rEFInd project) is https://efi.akeo.ie/ which is using GRUB's EFI filesystem support modules.

You could keep the kernel in /boot, there's really no purpose to encrypting /boot anyway.

I don't think it supports them at the moment, but there's no reason why systemd-boot can't use EFI FS drivers (there's dozens).

[skeevy420]

Grub only supports LUKS headers (no LUKS2 yet), but AFAIK systemd-boot doesn't support either.
If so, how is systemd-boot supposed to boot from a LUKS-encrypted boot partition?
It if really supports LUKS2 and native ZFS encryption I will switch for sure.
ZFS support looks especially unlikely to me, since encryption is only supported in the highly-experimental 0.8.x branch.

With Grub, there's a patch in a ZoL issue to hack it so pools can be created in a manner where /boot is unencrypted, the rest of the disk is encrypted, and you can unlock the rest via kernel command line, a key file, passphrase, etc and systemd-boot is the same only /boot can be encrypted since the kernel and ramdisk are in the stub. Grub will complain if that patch isn't used. I've used the 0.8.x branch of ZFS from day one without issue.

I just assumed on the systemd-boot/LUKS part...I don't really keep up with it outside of Grub and LUKS2.

[starshipeleven]

You could keep the kernel in /boot, there's really no purpose to encrypting /boot anyway.

I don't see much purpose in a separate /boot when you have the EFI partition.

I don't think it supports them at the moment, but there's no reason why systemd-boot can't use EFI FS drivers (there's dozens).

It's a design choice afaik. They envisioned using it with kernels in the EFI partition because you must have that anyway, so why not using it.

[Britoid]

I don't see much purpose in a separate /boot when you have the EFI partition.

It's a design choice afaik. They envisioned using it with kernels in the EFI partition because you must have that anyway, so why not using it.

The EFI partition is not very big.

[bachchain]

The EFI partition is not very big.

The EFI partition can be as big as you want it to be.

[Kano]

GRUB does not store the kernel+initrd in the ESD, that means that systemd-boot (old name gummiboot) has a bigger attack vector. /boot does not need to exist if you enter the password twice or store it inside the initrd. If you want to do an evil maid attack with the ESD it is still possible, but harder as the grub.cfg itself is not stored in the ESD. At least it would be different, you would need to enable an EFI keylogger and then chainload to GRUB EFI. The Linux Foundation loader already solved the Secure Boot part in this case. Basically Fedora (and others like Ubuntu/Debian who reused the patches) began to disable lots of GRUB features if they detect Secure Boot, you can not scan for files, use loopback (because the modules are not signed and not inside the GRUB.EFI like the newly added ones), chainload to EFI (the last maybe because of shim). I don't see a security gain if it is still possible to pass kernel options without a password without encryption. You own the system in seconds this way

[Britoid]

The EFI partition can be as big as you want it to be.

Yes but said size is by default set by the factory, and if /efi gets full of EFI binaries there's no way to sanely clean out anything unused automatically.

Where as /boot you have full control over.

[Britoid]

GRUB does not store the kernel+initrd in the ESD, that means that systemd-boot (old name gummiboot) has a bigger attack vector. /boot does not need to exist if you enter the password twice or store it inside the initrd. If you want to do an evil maid attack with the ESD it is still possible, but harder as the grub.cfg itself is not stored in the ESD. At least it would be different, you would need to enable an EFI keylogger and then chainload to GRUB EFI. The Linux Foundation loader already solved the Secure Boot part in this case. Basically Fedora (and others like Ubuntu/Debian who reused the patches) began to disable lots of GRUB features if they detect Secure Boot, you can not scan for files, use loopback (because the modules are not signed and not inside the GRUB.EFI like the newly added ones), chainload to EFI (the last maybe because of shim). I don't see a security gain if it is still possible to pass kernel options without a password without encryption. You own the system in seconds this way

GRUB doesn't meld with secure boot, it uses its own stack. The features are disabled because they have been used to work around secure boot.