From what I know UEFI and its Secure Boot are deeply problematic and certainly not the way forward.

See: https://en.wikipedia.org/wiki/Unified_Extensible_Firmware_Interface#Criticism

Also here it says:

In case of SecureBoot the UEFI system which needs to validate the signatures is not open source. And even if it would be open source this does not mean that systems come pre-installed with the key you used for signing.

So I am asking if there is an open source version of what UEFI's Secure Boot aims to do?

closed as primarily opinion-based by Rui F Ribeiro, Satō Katsura, GAD3R, Thomas Dickey, G-Man Jun 12 '17 at 4:30

Many good questions generate some degree of opinion based on expert experience, but answers to this question will tend to be almost entirely based on opinions, rather than facts, references, or specific expertise. If this question can be reworded to fit the rules in the help center, please edit the question.


Closest thing to UEFI alternative is coreboot.


Actually, the part that verifies Secure Boot signatures is open. It's a part of Intel's TianoCore. The problem is, when you buy off-the-shelf hardware there's no way to check what the hardware vendor actually put inside. But that's a general problem with PC firmware, not Secure Boot as such.

The system-side of Secure Boot in Open Source operating systems themselves - eg Linux or FreeBSD - is fully Open Source as well.

Secure Boot does have its problems - the signing scheme is just awful - but "lack of openness" is not one of them.


This is not really a direct alternative and may not be quite what you're looking for, but a similar solution that requires a TPM (Trusted Platform Module) is called 'Trusted Boot', or tboot. It differs in some key ways, but its ultimate goal is the same - to establish a level of trust in the boot chain and state of your system.

Tboot itself is actually an open source implementation of a concept called an MLE, or Measured Launch Environment. In a nutshell, its a blob of binary code that executes and utilizes Intel TXT to put the machine into a privileged and trusted state, where it can then take measurements (SHA-1 hashes in TPM 1.2) of the OS and related components, and push them to the TPM to be stored securely. For example in Linux, tboot can be setup to execute immediately before the kernel loads and it will generate hashes of the kernel binary, kernel parameters, and initramfs image and send them each to the TPM.

Additionally, a TPM and compatible motherboard/BIOS allows for measurements to also be taken of various components in your system much earlier in the boot process, such as the BIOS image itself, custom BIOS settings, PCI card firmware (GPU, NIC, and more), the bootloader (grub, for instance) and more. You may be wondering what good are those measurements? Well, not much by themselves. Instead, the TPM can be used to do a number of things if and only if those measurements are a specific value, such as reading/writing to TPM NVRAM, or decrypting a key only the TPM can decrypt. These measurements can also be conveyed securely (and anonymously, if desired) to another party, so that party can establish trust remotely. Subsequently, a system can be designed to only boot up or execute some software if the TPM has some specific measurements in its PCRs, meaning it booted a specific set of software - ie it provides integrity.

Fundamentally, the TPM and tboot combined provide a broad spectrum of system coverage and at least on paper from what I understand can be extended to measure/hash virtually anything you want by using an API to send hashes to the TPM for storage. One important thing to note is that hashes do not simply get loaded plainly into the TPM. Instead, when a hash is to be stored in an internal register in the TPM (PCR, or Platform Configuration Register), it is concatenated with the previous value of the register, and the blob is hashed and the result stored in the register. The result is that each register accumulates state, and any difference along the way causes the end value to change. This is called a tpm 'extend'.

Fundamentally, I think the TPM and tboot offer much more capability than secure boot does. The TPM is a sort of general purpose cryptographic coprocessor that can be used for secure storage, RNG, system state reporting to other hosts (attestation), and more.

Unlike Secure Boot, which utilizes signatures and halts the bootup process if a signature doesnt check out, the TPM/tboot does not use signatures and does not directly stop the boot sequence. Rather, a system has to be designed to fail boot up by requiring the TPM to perform some action, which it will only do if the system is in some defined state, if so desired.

As for your concern about the open-source bit and transparency of it all, even tboot/TPM delves into a stratum of implicit trust, and really, its an unavoidable leap of faith in my mind, unless literally every piece of software was open source, and the hardware as well, and hardware schematics were understood. In the case of tboot and the TPM, this implicit trust goes all the way down to the chipset and the processor itself. Supposedly a public key checksum is embedded into the chipset that is used by processor microcode to start the chain of trust. This checksum isn't explained completely in texts I own, but what is explained is that a signature is verified by processor microcode on a block of code resident within the BIOS image called the BIOS ACM for the SRTM, or SINIT ACM for DRTM. In order to verify a signature of course, a public key must be used and my guess is that the public key is embedded in the ACM for space reasons and verified against this hardware resident checksum mentioned earlier.

  • There is no signature embedded in a CPU. Both S-CRTM and D-CRTM measure the firmware to establish a root for the subsequent chain of trust. – fpmurphy Jun 10 '17 at 9:08
  • Thanks, I knew I remembered that incorrectly. I meant to say a checksum of a public key embedded in the chipset that is used by processor microcode. The root of trust effectively begins with this hardcoded piece of data. Also, when you say 'firmware', I assume you mean their respective BIOS and SINIT ACMs and BIOS/firmware platform images, not PCI card firmware, which is not measured by tboot (DRTM) – krb686 Jun 10 '17 at 10:13
  • In other words, the BIOS or UEFI firmware is not the implicit root of trust, it is the processor/chipset. – krb686 Jun 10 '17 at 10:17
  • As I understand it, it is the ACM binary blob, which is part of the firmware. The processor simply measures and validates the ACM using a hash and compares the resultant hash to an embedded hash in the firmware. – fpmurphy Jun 13 '17 at 1:54
  • If you're thinking that the processor simply hashes the ACM and does a comparison, that's not what I've read. Of course, I haven't verified this nor would I even know how to, however see Intel Trusted Execution Technology for Server Platforms, pg 18, William Futral and James Greene. – krb686 Jun 13 '17 at 3:55

Not the answer you're looking for? Browse other questions tagged or ask your own question.