BIOS vs EFI vs coreboot vs libreboot

Patrick · November 12, 2017, 7:58pm

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.

For BIOS, there is no off-the-shelf backdoor code.
For EFI, off-she-shelf backdoor code is readily available from github. - GitHub - Cr4sh/SmmBackdoor: First open source and publicly available System Management Mode backdoor for UEFI based platforms. Good as general purpose playground for various SMM experiments.

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.

torjunkie · November 19, 2017, 10:56am

Noted!

Patrick · November 12, 2023, 3:53am

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]

Patrick · November 12, 2023, 4:17am

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.

neo0xff · November 14, 2023, 12:01am

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!

Patrick · November 14, 2023, 8:01am

Would also break LKRG.

Patrick · January 25, 2024, 12:13pm

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.

HulaHoop · June 19, 2024, 6:20pm

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.

Patrick · June 20, 2024, 9:14am

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

Patrick · July 15, 2024, 7:09pm

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

nurmagoz · July 7, 2026, 8:14pm

Enabling UEFI is using the current proprietary software instead of the old software. So in order to overcome any problems (if any) with UEFI better to be enabled by default.

All VMs (debian and others) im installing are with UEFI, no issues.

Patrick · July 8, 2026, 11:38am

As far as Whonix is concerned, inside VirtualBox and KVM, both BIOS and EFI are fully Open Source / source-available. [1]

The assumption “old” has to be rejected.

The assumption “old = bad” here has also to be rejected.

Details:

For VMs, the worthwhile goal is Sovereign Boot, once available/possible.

[1]
VirtualBox BIOS:
There’s a compilation toolchain software freedom issue. Details here:
VirtualBox Unavailable in Debian main due to Licensing Issues
It’s not closed source. The required compiler is source-available, under OSI certified license but not FSF certified license yet.

nurmagoz · July 8, 2026, 6:04pm

How old is better when no Secureboot or TPM (even if currently not mainly used) and microcode updates (critical) available? From security point view this is a disaster.

So working old software doesnt mean necessarily its secure software. And in our case the old hardware are deprecated/insecure.

The only way to justify supporting old hardware is when we for example say that we are FSDG distro, meaning yes we care about security when only its literally full free software, so microcode will be out of the scope, but thats not the current case.

So there is no avoidance from the support of the current new supported software/hardware and remove the support from the deprecated ones, if we are talking about security.

Patrick · July 8, 2026, 6:29pm

Secure Boot with Microsoft key isn’t worthwhile. References:

Less worthwhile with leaked Microsoft secure boot key.

Secure Boot brings shim into the mix, which is also not great… →

github.com/rhboot/shim

remove shim HTTP boot due to security issues

opened 02:15PM - 11 Feb 24 UTC

closed 07:02PM - 14 Feb 24 UTC

adrelanos

**short summary:** Please remove shim HTTP boot due to potential future secur…ity issues and because it does not belong into shim. **long reasoning:** [CVE-2023-40547](https://thehackernews.com/2024/02/critical-bootloader-vulnerability-in.html) had a high CVE score, 9.8 of 10. From my perspective as a user, shim's HTTP boot feature is, * highly surprising, * seems highly unnecessary, * seems to be not used much. [1] * It's against unix philosophy. > Write programs that do one thing and do it well. It's also against what shim says about itself in its own readme, quote: > shim is a trivial EFI application that, when run, attempts to open and execute another application. It will initially attempt to do this via the standard EFI LoadImage() and StartImage() calls. If these fail (because Secure Boot is enabled and the binary is not signed with an appropriate key, for instance) it will then validate the binary against a built-in certificate. If this succeeds and if the binary or signing key are not forbidden then shim will relocate and execute the binary. HTTP boot does not seem simple at all and it's not as seen by the recent CVE. Why would HTTP boot be integrated into shim itself? Wouldn't that be much more useful if implemented as an additional, optional EFI executable? Why would shim re-implement networking, HTTP? Why would need to become almost it's own full operating system? GNU GRUB already has network boot functionality. So has the initramfs generator dracut. Why would this be needed also in shim? shim HTTP boot [was introduced without much of a rationale](https://github.com/rhboot/shim/commit/3d79bcb2651b9eae809b975b3e03e2f96c067072) and then [building got enabled by default without rationale](https://github.com/rhboot/shim/commit/9b0c281db4ca94ef4299911bd966eac8f75877f2). **high security impact:** I am not using HTTP boot, doesn't matter? No, not really. This is not only exploitable by those few using HTTP boot. Local exploitation is also possible. Quote https://eclypsium.com/blog/the-real-shim-shady-how-cve-2023-40547-impacts-most-linux-systems/ > The vulnerability can also be exploited locally by an attacker with enough privileges to manipulate data in the EFI Variables or on the EFI partition. This can be accomplished with a live Linux USB stick. The boot order can then be changed such that a remote and vulnerable shim is loaded on the system. This shim is then used to execute privileged code from the same remote server, all without ever disabling Secure Boot. **change request:** Therefore, could you please, * A) preferably completely remove the HTTP boot feature? Or, * B) If not removed, please at least disable building HTTP boot by default (as it was in the past). Or, * C) disable the feature by default. **documentation request:** In case HTTP boot is not removed, please at least document the feature. **related source code file:** https://github.com/rhboot/shim/blob/main/httpboot.c ---- [1] I performed a web search and barely found anyone talking about using shim HTTP boot let alone how to do that.

Without full Verified Boot, without Sovereign Boot, it’s not worthwhile.

TPM for? Verified boot / Measured Boot? Not needed until implemented.

There are no microcode updates for VMs.

Note: This forum thread is in the Whonix forums. So the only place where Whonix - as long as runs “primarily” inside VMs (ignoring physical isolation) - could flip the BIOS vs EFI setting is on the virtualizer settings level. And for that - at the time of writing - no sufficient rationale exists.

Whonix doesn’t run on hardware yet until Whonix-Host Operating System Live ISO, Whonix-Host Installer is available.

Even if Whonix-Host existed, the decision of BIOS or EFI depends on the host hardware. It’s not something that can be adjusted from within Whonix source code level. Modern hardware comes with EFI by default anyhow and does not even have BIOS compatibility module. So your EFI-only feature request on modern hardware is automatically fullfilled without any changes by Whonix required.

nurmagoz · July 8, 2026, 7:05pm

Awesome, lets hope it can come soon.