UEFI Secure Boot #

This document gives an introduction to UEFI Secure Boot and the possible ways of executing the stboot bootloader as part of the UEFI handoff to the bootloader.

What is UEFI? #

The Unified Extensible Firmware Interface (UEFI) specification was invented around 1998 by the Intel Corporation and kept confidential until 2006. In 2012, the “Secure Boot” feature got introduced to the specification. The specification main goal is standardization among the firmware ecosystem.

What nowadays users see as UEFI firmware is mostly the UI and the bootloader interface called “BDS” which loads a special crafted PE32 executable after firmware handoff to the bootloader. The most famous UEFI firmware implementation is the TianoCore project.

How does UEFI Secure Boot work? #

The visualization shows how the UEFI boot sequence starts from power on to shutdown.

Security (SEC) #

The SEC stage represents the initial code execute as part of the UEFI firmware. It initializes the basics like Cache-As-RAM, serial console, cpu register and more. This stage is also known for start further verification of the later stages.

Don’t be mistaken UEFI Secure Boot doesn’t start here nor it protects this component.

Pre-EFI Initialization Environment (PEI) #

The PEI stage mainly initializes the DRAM and configures parts of the platform.

Don’t be mistaken UEFI Secure Boot doesn’t start here nor it protects this component.

Driver Execution Environment (DXE) #

The DXE stage is the biggest one in the UEFI ecosystem. PCI Device Tree enumeration, Device Drivers, ACPI, SMBIOS, Graphics and more is initialized here. It also contains all drivers for accessing filesystem, network and doing cryptography. The stage will also configure/enforce UEFI Secure Boot and load external code called option roms.

UEFI Secure Boot starts here not at the beginning but somewhere in between as part of the dependency tree. It protects the BDS stage, option roms and everything after the BDS stage.

Boot Device Selection (BDS) #

This stage tries to locate and execute all bootloader application as part of the boot order.

UEFI Secure Boot protects here the execution of the bootloader.

PKI #

UEFI Secure Boot comes with a lot of key types. It also is often pre-provisioned by the hardware vendor with multiple keys instead of one to allow booting different operating systems and creating something like the web of trust model in firmware.

UEFI Secure Boot Execution #

This diagram shows the execution flow with the decision tree from initialization till bootloader execution.

DXE #

graph LR
A(DXE Invocation) --> B{SB Enabled?}
    B -->|Yes| C{PK verify KEK?}
    B -->|No| D(Boot any BL)
    C -->|Yes| E{KEK verify db/dbx?}
    C -->|No| F(Do not add to cert store)
    E -->|Yes| G(BDS Stage)
    E -->|No| H(Do not add to cert store)

BDS #

graph LR
    G(BDS Stage) --> I{BL hash in dbx}
    I -->|Yes| J(Stop execution)
    I -->|No| K{BL Signed?}
    K -->|Yes| L{BL Signatue in dbx?}
    K -->|No| M(BL Hash in db?)
    L -->|Yes| J
    L -->|No| N{BL Signature in db?}
    M -->|Yes| O(Execute BL)
    M -->|No| P(Stop execution)
    N -->|Yes| O
    N -->|No| P(Stop execution)

Why do we need Secure Boot? #

UEFI Secure Boot comes with an ownership model which allows you to build your own root-of-trust beginning with the firmware by deploying keys via physical presence interface. In-short you are able to verify the bootloader which is loaded by the firmware in order to protect from bootkits.

1. On some systems, UEFI Secure Boot is required for doing TPM 2.0 measurements during startup. Since ST utilize the TPM 2.0, it is a requirement. The UEFI specification doesn’t match the real machines firmware implementation. You can only know for sure when Secure Boot is enabled inside the UEFI firmware configuration by yourself.
2. The Secure Boot transits from the firmware level to the bootloader application as part of the firmware handoff procedure. Therefore Secure Boot is enabled on the most platforms nowadays, requiring to support it for Linux distributions and for ST as well. It became the de-facto standard nowadays on modern systems
3. UEFI Secure Boot reduces the attack surface of the UEFI firmware itself because it requires option roms (PCI hardware firmware) to be signed by the OEM/Microsoft. Without this protection mechanisms it is possible to attack the firmware itself by providing a malicious option rom.

Take aways before moving on #

• Nowadays all systems comes with UEFI firmware which provides a mechanism called Secure Boot. Under the link here provided there should be an extensive documentation about the mechanism protection and transitioning to the bootloader loaded after the end of the firmware.
• On some systems, UEFI Secure Boot is required for doing TPM2 measurements during startup.
• UEFI Secure Boot comes on the most systems with pre-provisioned keys from Microsoft and the OEM/ODM vendor. Those keys are set in stone and can only be revoked by manually provisioning (physical presence in the BIOS menu) new keys.
• There is an exception to manually provisioning on server systems offering the feature as paid BMC addon which comes with API access for easy provisioning.
• The most users tend to disable UEFI Secure Boot on server systems or using the standard signed SHIM model as part of common Linux distribution like Redhat, CentOS, Ubuntu and Debian. This enables them without changing the keys to boot their favourite Linux distribution.
• UEFI supports CRL but manages that really really bad. It also comes with size constraints due to limited CRL storage inside firmware.

ST Deployment Options #

In this flow diagram you can see possible routes of integration:

graph LR
A(UEFI Secure Boot) --> B{LinuxBoot support?}
    B -->|Yes| C(Embed into firmware)
    B -->|No| D{Secure Boot enforced?}
    D -->|Yes| E{Factory Keys?}
    D -->|No| F(Unsigned Measured Boot)
    E -->|Yes| G(SHIM/MS Signing)
    E -->|No| H(Custom Keys)
    G --> I{MOK Support}
    I -->|Yes| J(Prebuilt & Signed Artifacts)
    I -->|No| K(Source Code only)

Learn more #

If you want more detailed information on UEFI Secure Boot, refer to the following documentation:

• Tianocore EDk2 Official
• Rodsbooks

Moreover, the stboot bootloader itself comes as Unified Kernel Image package, introduced by the UAPI group.