coreboot Security Features

Print
You are here:

Overview

The Basic Input/Output System (BIOS) is the very first piece of software that is run when a computer is turned on. Traditionally the functions of BIOS were to identify, initialize, test and configure the hardware, then pass control to an Operating System (OS). “Legacy” BIOS has support for ancient hardware such as floppy disk drives and has other limitations such as limited address space. Unified Extensible Firmware Interface (UEFI) is a newer specification that addresses Legacy BIOS limitations and has added more features over time. UEFI is commonly referred to as “BIOS” due to the familiarity with the term. Major manufacturers such as Intel are moving completely away from Legacy BIOS to UEFI.

coreboot is an alternative to traditional proprietary BIOS. It is designed to be small, fast, secure and perform the minimal number of tasks in order to get the system up and running. In addition, it is an open source project, so the source code is available for inspection and building customized firmware.

 

coreboot Boot Process

The coreboot booting process consists of 4 stages:

bootblock

The first stage is the “bootblock” which does the most basic tasks for the CPU, such as loading microcode, setting 32 bit mode, and setting the stack pointer for the next instruction.

romstage

The second stage is the “romstage”. The romstage sets up the onboard cache to use as RAM before DRAM is initialized, known as “cache-as RAM” setup. It also calls the Intel Firmware Support Package (FSP) which is an Application Programming Interface (API) specific to the CPU which initializes on-chip functionality. It then initializes memory so that DRAM can be used.

ramstage

The third stage is “ramstage”. In this stage the system is running in DRAM and it initializes the devices and functions of the hardware.

payload

The fourth and final stage of coreboot is the “payload”. The payload is a third-party binary application that is primarily used to boot an OS or application. In the case of Protectli’s coreboot configuration, this payload is Tianocore/edk2 (UEFI payload) for the UEFI implementation.

 

BIOS Security

As computers have evolved with more functionality, they have also become more vulnerable to security threats. Threats now include not only software viruses and malware, but threats to the BIOS that initially boots the computer. These attacks can persist across reboots and OS updates so it is critical that they are mitigated. The coreboot implementation for the Protectli VP4600 contains multiple security features to mitigate vulnerabilities to the BIOS firmware.

As noted above, the BIOS process and “booting” a computer involves multiple stages. In order to guarantee a secure system, each stage must be verified as secure before it is loaded. In a secure system, a “Root of Trust” is established. In coreboot, the firmware is cryptographically signed to establish the Root of Trust. A “Chain of Trust” is then established as cryptographic signatures are checked against the additional modules before they are loaded into the system.

Verified Boot

In coreboot, “Verified Boot” is the feature / mechanism to provide the Root of Trust and Chain of Trust to ensure that the firmware has not been compromised. The Protectli VP4600 coreboot image has been “signed” with a cryptographic key. This establishes the “Root of Trust” for the secure boot process. Verified Boot adds another stage in the boot process called the “verstage”. It is called right after bootblock and it adds the hooks into the process so that the subsequent stages can be verified cryptographically before they are loaded in order to establish the Chain of Trust.

Verified Boot requires 2 partitions in the BIOS chip for 2 copies of coreboot. When coreboot with Verified Boot is flashed into the BIOS chip, it writes 2 copies of the image. One partition is read-write and the recovery partition is read-only. Booting starts from the recovery partition, which verifies the read-write partition. If the read-write partition is verified, the system will boot from that partition. If it fails verification, the system will boot from the recovery partition and send a message to the screen that it is booting from the recovery partition.

BIOS Lock

Another security feature is BIOS Lock. When BIOS Lock is enabled in the BIOS menu, it protects the recovery partition from being overwritten. The recovery partition is used to verify the read-write partition. When updating a version of coreboot, only the read-write partition is updated. If updating to a different BIOS such as AMI, BIOS Lock must be disabled so that the entire BIOS chip can be written.

UEFI Secure Boot

Verified Boot ensures security of the boot process through loading the Payload. UEFI Secure Boot is an additional security feature which verifies the security of an OS. It essentially adds the OS to the Chain of Trust by verifying the signature of the OS before loading it. It requires support in the OS. Popular OSes such as Windows and Ubuntu support Secure Boot, with adoption steadily growing. These OSes have their public keys included in the coreboot image in order to verify the integrity of the OS. If Secure Boot is enabled in the BIOS menu, it will not load the OS if the OS does not support Secure Boot, the public key for the OS has not already been installed in the firmware, or the OS fails its integrity check. Therefore, Secure Boot must be disabled in the BIOS menu in order to load an OS that does not support Secure Boot. Examples of OSes that do not currently support Secure Boot are OPNsense and other FreeBSD-based OSes.

Measured Boot

Measured Boot is a security feature that “measures”, or checks, each stage of the boot process. In addition to Verified Boot, Measured Boot also writes the hash digest from each stage into a Trusted Platform Module (TPM) so that the OS can check/verify the value later. A TPM can be a separate physical component, referred to as discrete TPM (dTPM), or it can be implemented in firmware, known as firmware TPM (fTPM). The Protectli VP4600 supports an optional physical dTPM. If no dTPM is present, Measured Boot will not be utilized, but other Verified Boot, BIOS Lock and UEFI Secure Boot will still function correctly.

Disk encryption utilities such as BitLocker and LUKS can be used to encrypt disks. However, a downside is that the password to unencrypt the disk must be entered manually when the system is booted or disk is remounted. If supported by the OS, it can read the measurements stored in the TPM which were made during the Measured Boot process and can be used to automatically unencrypt the disk. This means that you will not need to enter your disk encryption password as long as the firmware and settings have not been tampered with.

Intel ME Disable

The Intel Management Engine (ME) is a complete stack on an independent subsystem that allows remote access to a system. In some cases, the ME can run even when the device is powered off. However, there have been multiple vulnerabilities over the years, and security conscious customers have wanted the ability to disable the functionality. Intel ME Disable is a feature which disables the Intel ME. The implementation of coreboot for the Protectli VP4600 has Intel ME disabled by default using the soft-disable method which is documented at this link: https://docs.dasharo.com/osf-trivia-list/me/#soft-disabling-me

Note that if the unit is reflashed with another BIOS, such as AMI, Intel ME will be reenabled and all of the security features mentioned above will be inactive.

Summary

Summary of coreboot security features on the Protectli VP4600:

Verified Boot – Always enabled

BIOS Lock – Enabled by default, can be disabled in BIOS Menu, must be disabled when flashing different BIOS, such as AMI

Secure Boot – Disabled by default, can be enabled in BIOS Menu, supported by Ubuntu, Windows, other OS

Measured Boot – Enabled by default, requires TPM for dTPM

ME Disable – Enabled by default, cannot be disabled

coreboot Updates and Flashli

When updating coreboot BIOS with these security features, only the read-write portion of the BIOS is updated. Therefore, the “flashrom” utility must use different arguments than when first flashing coreboot. Protectli has created and maintains a flashing utility, “Flashli”. Flashli will detect the current BIOS (coreboot or AMI), version, and then flash the BIOS. Given the multiple permutations of coreboot/AMI, fresh flash vs. update, platform, etc. Protectli strongly recommends using Flashli for BIOS updates rather than manual commands. Flashli can be found at this link.

As always, if you have any questions, please feel free to contact us at: support@protectli.com.

Table of Contents