"Security" comparison of Bootloaders/boot managers

Off Topic
1

I am currently on CachyOS, using GRUB and Btrfs snapshots.

It offers 4 boot managers:

  • systemd-boot
  • rEFInd
  • GRUB
  • Limine

I’d like to ask your opinions in terms of security (and attack surface) of these boot managers. I won’t include rEFInd.

Most of the stuff is taken from the CachyOS Wiki.

systemd-boot

Pros

  • UEFI only.
  • TPM PCRs are measured during boot.

Cons

  • No native support for Btrfs snapshots and snapshot booting is possible only with custom setups (not provided by CachyOS).
  • According to Madaidan “systemd contains a lot of unnecessary attack surface”. Though I am not sure whether this applies to systemd-boot or not.
  • If using a boot filesystem beyond the firmware’s default ones (FAT12/16/32), then separate ESP and XBOOTLDR partitions & EFI drivers need to be manually added.
  • Cannot find boot images on partitions other than its own ESP or the XBOOTLDR partition.

GRUB

Pros

  • Supports nearly all Linux filesystems.
  • Supports encrypted /boot partitions.
  • Supports Btrfs snapshot booting (via grub-btrfs-support on CachyOS).
  • TPM PCRs are measured during boot.

Cons

  • Large and complex, with many filesystem drivers (more attack surface compared to systemd-boot and Limine - correct me if I’m wrong).
  • Noticeably slower than systemd-boot and Limine.

Limine

Pros

  • It’s more modern compared to others.
  • Supports Btrfs snapshots via limine-snapper-sync, enabled by default on CachyOS with Btrfs.

Cons

  • /boot must use FAT12/16/32 or ISO9660. Other filesystems require additional setup.
  • Does not automatically add an entry to UEFI NVRAM. This must be done manually with efibootmgr, or handled automatically with limine-entry-tool (preinstalled on CachyOS).
  • TPM PCRs are not measured. Will fail TPM PCR0 Reconstruction test.
    • Fixable by booting UKI that uses systemd-stub as UEFI stub. The systemd-ukify can make this (see here).
    • Another workaround is to chainload another bootloader that measured TPM PCR (e.g. systemd-boot, GRUB).
1 Like
2

systemd’s postboot “attack surface” doesn’t matter when it comes to choosing a bootloader. If properly configured, an attacker wouldn’t have an option to corrupt the chain of trust order without resorting to sidechannel attacks.

1 Like
3

I think this is the wrong question, since x86 doesn’t really have any proper boot verification mechanism.

Instead what is your goal? Some brief suggestions:

  • Just protecting your data from theft/loss?
    • Use LUKS and call it a day.
  • Ensuring that someone with brief access can’t trivially tamper with it?
    • Consider moving your /boot partitions to a USB flash drive or using OPAL with a PBA in the read-only shadow region + LUKS.
      • the cool part of OPAL is that when it is locked your regular partitions can’t be read or written to
  • More extreme?
    • Do the above and then add on dm-integrity and also sign your own secure boot chain and get an HSI-4 laptop and put some glitter/paint on all the screws and across some plugs on the ports.
3 Likes
4

What is your go-to HSI-4 laptop? Any particular Dell or HP model? Does Lenovo still provide confidence for your uses? Any other manufacturers I should check out?

5

I just don’t want to use an “old and complex” bootloader, it’s an OCD thing of mine. But should it matter that much when LUKS is enough for me?

6

Arch based distros like CachyOS, has tools to chain the boot natively with systemd-boot. If you were using another distro I’d give a try on Limine but on Arch, systemd-boot seems more documented and easy to implement with less friction.

2 Likes
7

What happens on x86-based Chromebooks with coreboot/vboot like the Pixelbook?

1 Like