BIOS vs EFI vs coreboot vs libreboot

Development
1

I haven’t made up my mind yet. Here are some information which are conflicting.

Some thing for Advanced Security Guide - Whonix.

coreboot / libreboot should be preferred above all else since it is Libre Software / Open Source.

But since coreboot / libreboot has very limited hardware support, the other options also need some documentation / recommendation.

There is no feature like secure boot for coreboot / libreboot yet?

EFI should be discouraged because it is more open and standardized yet it is still obscure closed source like BIOS.

So infections that persist even reinstallations are more likely when using EFI. Therefore, In the question is only EFI vs BIOS, it would mean a clear recommendation for BIOS.

EFI and secure boot should be encouraged. AEM can measure malicious modifications, but secure boot can provide a chain of verification from the processor the the firmware (EFI) to the bootloader to the kernel.

There is an issue when secure boot gets implemented as restricted boot, but one could use the presigned shim bootloader or deploy its own secure boot keys.

Debian is working on secure boot.

https://wiki.debian.org/SecureBoot

Qubes does not have it yet. Other linux operating systems may already support it.

2 Likes
2

Noted! :slight_smile:

1 Like
3

Whonix for VirtualBox developer builds now are compatible with both, legacy BIOS booting and EFI booting.

Booting with SecureBoot enabled is also supported.

It is therefore possible to switch VirtualBox settings:

  • EFI: on / off
  • SecureBoot: on / off [requires EFI]
4

Enabling SecureBoot breaks tirdad.

This is because tirdad isn’t signed by Debian but with the local DKMS yes. That key however isn’t enrolled by default into the system’s keyring (MOK).

If there’s a solution and if enabling SecureBoot (or even EFI) in VMs makes sense yet is yet to be determined.

related:

1 Like
5

Secureboot on VMs seems absurd, it’s already hard dealing with it on a host. But if you do need any help testing anything related to this out, please @ let me know and I will do!

6

Would also break LKRG.

7

EFI still causing issues up to this day.

EFI inside VirtualBox breaks Debian Installer (the traditional one, not Calamares):
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1036019

Therefore probably better to not enable EFI by default. Having EFI booting compatibly however is a nice feature.

8

The requirements to have EFI are installing the ovmf package on Debian and flipping a couple of options to change machine type and select the firmware with the MS sig. It is easily enabled nowadays compared to the past however with the guest side plumbing like EFI partitioning on the disk and having a signed kernel version, the EFI cannot “see” or start the image. However a vanilla iso from Debian is readily started.

9

I don’t know if the last built Whonix KVM image already comes with EFI booting compatibly. It might not. New Whonix KVM image required to test this for real.

Secure Boot support:

It depends which OVMF firmware is in use. Afaik (not re-tested now):

  • /usr/share/OVMF/OVMF_CODE_4M.ms.fd: EFI SecureBoot with Microsoft key
  • /usr/share/OVMF/OVMF_CODE.fd: EFI without SecureBoot

I figured that out when making sure the Kicksecure ISO is compatible with EFI SecureBoot inside QEMU for simplified testing of ISO images.

So,

  • A) enabling vs not enabling EFI by default, versus
  • B) enabling vs not enabling Secure Boot by default,

are two different decisions to make.

These are connected in so far that

  • If enabling Secure Boot by default, enabling EFI by default is a prerequisite.
  • However, in theory we could enable EFI by default but not Secure Boot.

For Secure Boot there is a dedicated forum thread: enable Linux kernel gpg verification in grub and/or enable Secure Boot by default

10

For host operating systems (Kicksecure, Whonix-Host), the user could opt-in Secure Boot DKMS Signing Key Enrollment.