Coreboot Explained: Open Source Firmware, Payloads and Verified Boot

Coreboot is a free and open source project that replaces the proprietary BIOS or UEFI firmware on a computer. It does the minimum hardware initialization needed to make the machine usable, then hands control to a separate program called a payload (SeaBIOS, edk2 UEFI, GRUB, a Linux kernel or depthcharge) that actually boots the operating system. Chromebooks have shipped it since 2012, and it adds verified boot and TPM measured boot on top.

This guide goes one level deeper than our post on how the motherboard evolved from BIOS to UEFI, TPM and the BMC. We read the coreboot documentation at doc.coreboot.org (built from the 26.09 release tree), the coreboot source tree's own README and documentation index, the Chromium OS verified boot and firmware recovery design documents, the LinuxBoot and flashrom project pages, the LVFS documentation and NIST SP 800-147 and SP 800-193. Every stage name, Kconfig option, PCR number and command below comes from those sources. Where something depends on your board, we say so.

Key takeaways

• Coreboot is not UEFI. It initializes hardware and exits. The payload you build into the flash image decides how the OS is loaded, and there is no way to choose a different payload at runtime.
• A coreboot boot runs in stages: bootblock, optional verstage, romstage, postcar, ramstage, then the payload. Each stage is a separate binary stored in the coreboot file system (CBFS) inside the flash chip.
• Open source does not mean blob free on modern hardware. Most current Intel and AMD boards still need vendor binaries such as CPU microcode, Intel FSP memory and silicon init, and the Intel Management Engine or AMD security processor firmware, which share the flash chip but are not part of coreboot.
• Verified boot (vboot) uses a hardware write protected read only region holding a root public key, plus two signed read/write copies (A and B) so updates can fail safely and recovery always works.
• Measured boot hashes every CBFS stage and blob into TPM PCR 2 (runtime data into PCR 3) and keeps an event log you can read with cbmem -L and check against cbfstool output.
• Before you flash anything, take and verify a full backup, confirm the exact flash chip and board, and have an external programmer ready. A failed flash with no recovery path leaves a board that will not start.
• For audits, open firmware lets you rebuild and verify what is on the chip, and coreboot can embed a CoSWID based SBOM in the image.

What is coreboot, and how did it grow from LinuxBIOS?

The coreboot README in the source tree states the goal plainly: coreboot is "a Free Software project aimed at replacing the proprietary firmware (BIOS/UEFI) found in most computers." It performs the required hardware initialization, then passes control to a different executable, the payload. The documentation index in the same tree describes the design philosophy as doing "the bare minimum necessary to ensure that hardware is usable" and then getting out of the way.

From Linux as the BIOS to the core boot code

The project started life as LinuxBIOS, and the name was literal. In his 12 January 2008 message to the project mailing list announcing the rename, Ron Minnich explained that early LinuxBIOS meant "core boot code" plus a Linux kernel in the flash chip, aimed at cluster nodes. In 1999, 1 MB flash parts were common on those nodes, enough for a Linux 2.2 kernel. By 2001, flash sizes on the target systems had shrunk to 256 KB, and Linux 2.4 needed about 1 MB, so Linux no longer fit. Builders started pairing the core boot code with smaller loaders such as Etherboot, FILO, GRUB 2, Open Firmware and even a TianoCore UEFI implementation.

The name stopped matching the software. As Minnich put it, what LinuxBIOS had really meant for years was the core boot code, and the word "Linux" made companies assume Linux had to live in ROM. After discussing candidates with many companies, the project chose "coreboot" and switched in January 2008, which the message calls the tenth anniversary of the first LinuxBIOS boot, counted in octal (eight years). The coreboot docs keep a trace of that history: the payloads page notes that Linux as a payload "was the configuration that gave coreboot its original name, LinuxBIOS."

Where coreboot ships today

The coreboot project does not ship binaries. Its distributions page describes coreboot as "a toolbox that others can use to build boot firmware," and splits users into two groups.

1. Hardware that ships with coreboot. All ChromeOS devices (Chromebooks, Chromeboxes and similar) released from 2012 onward use coreboot as their main system firmware, and from the 2013 Chromebook Pixel onward the embedded controller firmware is open source too. The page also lists several makers of Linux laptops, embedded PCs and network appliances that ship coreboot based firmware, often the Dasharo distribution.
2. After market firmware. Community distributions build images for hardware that originally shipped with something else: Dasharo, Heads, Libreboot (which strips every board that needs binary components), and projects that build upstream coreboot with an edk2 payload for x86 Chromebooks.

On servers, the coreboot FAQ is candid: there is "next to no support for 'server' platforms (multi-socket and similar things)" on Intel, and AMD Ryzen platforms outside Chromebooks and AMD reference boards are "currently not well supported." The FAQ lists supported Intel client generations from Sandy Bridge (2011) to Meteor Lake (2023), and AMD SoCs from Stoney Ridge to Phoenix.

Timeline

The source tree README says releases happen every quarter and are best treated as "snapshots of the codebase." Distributions and device makers pick a commit, test it on their boards and ship it.

Is coreboot the same as UEFI?

No, and the coreboot FAQ answers it directly. UEFI is a specification. Most UEFI firmware on retail hardware is a proprietary implementation built on top of the open source EDK II framework. Coreboot does not implement the UEFI specification at all. Its goal is "to just initialize the hardware and exit," which the FAQ argues makes it smaller and simpler, with faster boots and bugs that are easier to find and fix.

UEFI also covers boot device selection, firmware updates, a shell, networking and a setup menu, all of which coreboot leaves out; the FAQ says coreboot "does not, and will not contain a Wi-Fi driver." If your OS needs UEFI, build coreboot with edk2 as the payload.

What are the boot stages, and what does each do?

The coreboot architecture page says coreboot "consists of multiple stages that are compiled as separate binaries and are inserted into the CBFS with custom compression." The bootblock is usually uncompressed. Ramstage and the payload are usually LZMA compressed. LZ4 is also supported. Each stage loads the next at a given address, decompressing it if needed. Some stages are relocatable and cached in CBMEM, a reserved memory area, so resume from ACPI S3 sleep is faster.

bootblock

The bootblock is the first code the CPU runs after reset. It is written in assembly and its job is to build an environment where C can run: set up Cache as RAM for a heap and stack, set the stack pointer, clear memory for BSS, then decompress and load the next stage. On x86 it also applies CPU microcode updates, initializes a timer and switches from 16 bit real mode to 32 bit protected mode. If verified boot is enabled, the bootblock loads verstage next. Otherwise it loads romstage.

Cache as RAM

DRAM does not work yet at reset, because the memory controller has not been trained. Cache as RAM, also called non eviction mode, lets the CPU cache act like ordinary SRAM so C code has somewhere to keep its stack. It is switched on with vendor specific CPU instructions. Bootblock, verstage, romstage and postcar all run while Cache as RAM is active.

verstage

The architecture page describes verstage as "where the root-of-trust starts." It and its public key are assumed impossible to overwrite in the field. Verstage installs a hook that verifies each file before it is loaded from CBFS and each flash partition before it is accessed.

romstage

Romstage initializes DRAM and does early device init. On many Intel platforms this is where a binary memory init component runs, which is one reason the vboot documentation lists fspm.bin among the files in each firmware slot.

postcar

Postcar is a small stage that tears down Cache as RAM so code can run from real DRAM, then loads ramstage.

ramstage

Ramstage does the main device initialization: PCI devices, on chip devices, TPM init if verstage did not already do it, optional graphics, and CPU init including System Management Mode (SMM) setup on x86. It then writes the tables the payload and OS need: ACPI and SMBIOS tables on x86, coreboot tables, and device tree updates on Arm. Ramstage also locks the platform down before handing off. It write protects boot media, locks security related registers and locks SMM.

payload

The payload "resides in the CBFS and there's no possibility to choose it at runtime." Whatever you built in is what runs. The FAQ notes that coreboot tries to remove itself from memory after boot, but leaves CBMEM (boot log, tables, SMBIOS and ACPI data) and, on x86, SMM code that stays resident.

What are payloads, and how do you choose one?

The coreboot payloads page frames it this way: coreboot "merely does hardware init and then passes on control to another piece of software that we carry along in firmware storage, the payload." Any statically linked ELF binary can be a payload, loaded through coreboot's SELF format. The source tree's documentation index names the most common ones: SeaBIOS for PC BIOS services, edk2 for UEFI services, GRUB2, and depthcharge, "a custom boot loader used on Chromebooks."

SeaBIOS

SeaBIOS is an open source implementation of the classic PC BIOS interface. It was first written for emulators such as QEMU and can be built as a coreboot payload. The payloads page says it runs option ROMs "in a more complete fashion than coreboot" and supports Multiboot. Choose it when you need to boot an older OS that relies on legacy BIOS interrupts.

edk2 (UEFI)

edk2 is the open source development environment for the UEFI and UEFI Platform Initialization specifications. As a coreboot payload it gives you a UEFI boot interface and runtime services, which is what current Windows releases and most Linux installers expect. It is also how you get UEFI Secure Boot on a coreboot machine. If you go this way, the same key management questions apply as on any UEFI system; see our guide to Secure Boot with your own keys, enrolling PK, KEK and db on Linux and our look at Secure Boot certificate rotation in 2026.

GRUB2

GRUB2 is best known as the Linux bootloader, but it can be compiled as a coreboot payload so it lives in flash rather than on disk. The coreboot FAQ calls this "currently the most common approach to full disk encryption" among non UEFI payloads. GRUB in flash can also chainload SeaBIOS from CBFS, as the payloads page shows.

Linux and LinuxBoot

A small Linux kernel and initramfs can be the payload. That kernel finds the real OS kernel on disk or over the network and starts it with kexec. The coreboot docs list two benefits proponents cite: mature, well tested Linux drivers instead of firmware drivers that "often reinvent the wheel," and boot policy written with familiar tools such as shell scripts or Go and C programs. The coreboot FAQ notes this is sometimes called LinuxBoot.

depthcharge

depthcharge is the custom boot loader Chromebooks use as their payload. Because the payload lives in the signed read/write firmware slots, it is the part of the firmware that goes on to check and load the ChromeOS kernel, as the Chromium verified boot design describes. You will meet it on ChromeOS hardware and rarely anywhere else.

Heads

Heads is a distribution that bundles coreboot, Linux, BusyBox and custom tools to produce reproducible ROMs. The payloads page lists measured boot, kexec, GPG, one time passwords, TLS and firmware updates among its features, with the caveat that it "only works on a limited amount of mainboards."

Choosing a payload

What binary blobs remain, and why can't coreboot remove them?

Open source firmware on a current x86 laptop or desktop is open source where it can be. The coreboot FAQ says people who want a minimum of proprietary firmware are "restricted to older systems" or more expensive non x86 platforms, and that modern systems sold with coreboot "all require more proprietary binaries in addition to coreboot (e.g., Intel FSP)." Those binaries come from the silicon vendor, who has not released source or enough documentation to write an open replacement.

The measured boot documentation shows exactly which pieces sit in a typical Intel image, because it hashes every one of them. Its example event log includes:

• cpu_microcode_blob.bin, the CPU microcode updates the bootblock loads.
• fspm.bin and fsps.bin, the memory init and silicon init parts of Intel's Firmware Support Package (FSP), which coreboot calls as binary components.
• vbt.bin, the video BIOS table used for graphics init.
• SI_ME, the flash region holding Intel Management Engine firmware.
• SI_GBE, the integrated gigabit Ethernet region.
• SI_DESC, the Intel flash descriptor that defines the regions on the chip.

The coreboot tutorial adds a practical note: by default the build does not download the blobs git submodule. You have to switch on "Allow use of binary-only repository" in the General Setup menu when your board needs microcode or other binaries from it.

The Management Engine and the AMD security processor

The Intel Management Engine and AMD's Platform Security Processor are separate processors with their own firmware. Coreboot cannot replace them. The coreboot FAQ puts it clearly: coreboot and the ME "are completely separate entites which in many cases simply happen to occupy the same flash chip." Running coreboot "does not imply anything about the ME's operational state."

The FAQ also warns against casual changes. The ME is designed to run correctly with the HAP (AltMeDisable) bit set, entering a debug state that is "not normal, but not an error." Tools that cut modules out of the ME firmware often leave it in an error state, and the project says it does not know whether that state is as secure as the HAP bit alone, since removed modules might lock down important settings. Its advice: "we do not recommend messing with the ME firmware," and if you must, set the HAP bit with ifdtool first. For what these processors actually do and how admins can check their versions, see our Intel CSME and AMD PSP explainer.

Boot Guard and platform secure boot can block coreboot entirely

Some platforms check the first firmware code against a key fused into the chipset at the factory. The measured boot page describes Intel Boot Guard and AMD Hardware Validated Boot (Platform Secure Boot) as moving the root of trust for verification into hardware. That is good for the board maker's firmware and bad for anyone who wants to replace it: the coreboot FAQ warns that if Boot Guard is enabled, "getting coreboot to run will be difficult or impossible even if it is ported." Check with intelmetool -b on supported platforms before you plan a port.

Blob inventory at a glance

How do vboot and measured boot with a TPM work in coreboot?

Coreboot has two separate integrity features. Verified boot checks signatures and refuses or falls back when they fail. Measured boot records hashes in a TPM so something else can judge them later. The measured boot page notes that measured boot started as an extension of Google's verified boot but has since been decoupled, so you can use it without vboot.

If the difference between these ideas is new, our post on Secure Boot, trusted boot and measured boot covers it in general terms.

The vboot root of trust

The coreboot vboot page lists what Google's verified boot consists of: a root of trust, a special flash layout, firmware verification, firmware measurements, an update mechanism, build flags and an image signing process. The root of trust is "basically the read-only portion of the SPI flash." The page is unusually honest about what that trust assumes: the compiler did not insert extra code, the CPU executes its reset sequence as documented, the SPI flash returns only what was programmed into it, and the flash honors its write protect input.

That protection is physical. During manufacturing, the write protect pin on the SPI flash is grounded and write protect bits are set in the chip's status register. On x86 the protected area is typically one quarter of the flash. Without a hardware modification, that region keeps its factory contents for the life of the device. Chromebooks expose this deliberately with a write protect screw, which grounds the WP pin; removing it lets factory lines and advanced developers rewrite the whole chip.

The flash layout

vboot adds these regions to the image:

The recovery firmware in the read only region contains every stage from bootblock to payload plus microcode and FSP binaries. It typically knows how to write the storage device from a recovery image on a USB drive or SD card, and how to rewrite slots A and B.

The boot flow

The reset vector points into the read only bootblock. On first boot, verstage reads the root public key from the GBB and verifies the VBLOCK in slot A. If that is valid, it extracts the firmware signing key (1024 to 8192 bits) and verifies FW_MAIN_A. If that passes, coreboot loads romstage, postcar, ramstage and the payload from slot A. If slot A fails and slot B is not valid either, vboot falls back to the read only region and boots into recovery.

The Chromium OS verified boot design document explains the same chain from the ChromeOS side. A small read only stub computes a SHA-2 hash of the read/write firmware and verifies an RSA signature over it with a permanently stored public key, "ideally" 2048 bits or more. The read/write firmware has its own subkey and verifies the kernel. The document is clear that restricting the machine to Chromium supplied code "is not a goal." The aim is that when other code runs, the user can always reset the device to a known good state, with "no dependence on remote attestation."

A and B slots make updates safe

Each read/write slot is in one of three states: invalid, ready to boot, or successfully booted. The OS writes an update to whichever slot is not marked successfully booted. On the next boot, vboot tries a slot marked ready to boot. If that boot fails, vboot marks it invalid and falls back to the slot that last booted successfully. Only the OS can promote a slot from ready to boot to successfully booted, usually after it has been running stably for a while.

The vboot page's conclusion is the point of the whole design: as long as SPI write protection is in place, "the system is always recoverable." The worst case, a fully corrupted read/write area, fails the signature checks and drops into recovery from the read only region. The Chromium firmware boot and recovery document lists the failure modes this covers: an interrupted firmware update, an attacker who reprograms writable firmware through an unpatched kernel bug, and flash corruption. It lists as out of scope an attacker who opens the case and jumpers or replaces the flash chip, and exploits on other processors such as the embedded controller.

Enabling vboot in a build

The coreboot vboot page names the Kconfig options:

• VBOOT and COLLECT_TIMESTAMPS must be selected.
• Choose where verification starts: VBOOT_STARTS_IN_BOOTBLOCK or VBOOT_STARTS_IN_ROMSTAGE. Starting in bootblock allows a separate verstage with VBOOT_SEPARATE_VERSTAGE.
• VBOOT_RETURN_FROM_VERSTAGE lets bootblock reuse verstage's RAM for romstage when static RAM is small.
• vboot needs non volatile storage for its flags: VBOOT_VBNV_CMOS or VBOOT_VBNV_FLASH.
• A TPM is required.
• RO_REGION_ONLY lists files kept only in the read only region; VBOOT_ENABLE_CBFS_FALLBACK lets lookups fall back to the read only CBFS when a file is missing from the active slot.

Signing uses the vboot reference tools in 3rdparty/vboot: generate keys with create_new_keys.sh, build a GBB with gbb_utility, write the root and recovery public keys into it, then sign the read/write slots with sign_firmware.sh. The doc's worked example is for a specific board and hard codes offsets from that board's flash map, so treat it as a pattern, not a script to copy.

Measured boot: what goes into which PCR

The measured boot page explains how coreboot builds a static root of trust for measurement (SRTM) chain. The initial boot block measures itself and then each next piece before running it. Because the TPM is often not ready that early, measurements are first cached in an event log during bootblock and replayed into the TPM once it is set up. TPM_MEASURED_BOOT_INIT_BOOTBLOCK moves TPM init into bootblock instead.

What gets measured and where:

• CBFS files (stages and blobs) are hashed as raw data before decompression, excluding the CBFS header, and extended into PCR 2 by default (PCR_SRTM).
• Runtime data that changes with external input, such as a memory training cache, goes into PCR 3 by default (PCR_RUNTIME_DATA) so it does not break precalculated PCR 2 values.
• With the CHROMEOS option set, PCR 0 holds a SHA-1 of the GBB flags and PCR 1 a SHA-256 of the GBB hardware ID. Without it, PCR 0 is unused and the GBB flags and HWID go into PCR 1.
• Coreboot uses three or four PCRs and leaves PCRs 4 to 7 empty.

That last point matters if you have tooling that expects the PCR layout of a typical UEFI PC. Our post on TPM 2.0 PCRs and what each one measures describes the conventional allocation. On coreboot, PCR 2 carries almost the whole firmware story, and the PCR values a disk encryption policy or attestation server sees will differ from a UEFI machine's.

Hardware roots versus software roots

On a plain coreboot system the initial boot block measures itself, so its root of trust is "rooted in software." Boot Guard and Hardware Validated Boot move verification of that block into hardware, but the measured boot page notes Boot Guard's measurement mode "was never deployed." Dynamic roots of trust (Intel TXT, AMD SKINIT) are separate and use PCRs 17 to 22.

How is coreboot built, and what safety steps apply before flashing?

The safest way to learn coreboot is to build it for QEMU first, where a mistake costs nothing. The steps below follow the official tutorial (part 1) in the coreboot docs.

Step 1: install build dependencies

On Debian based systems the tutorial lists:

sudo apt-get install -y bison build-essential curl flex git gnat \
  libncurses-dev libssl-dev zlib1g-dev pkgconf python-is-python3

It also gives the equivalent pacman and dnf lines. The host tools and unit tests use your system compiler, and the project aims to support the compilers in the oldest supported LTS distributions, currently Ubuntu 24.04 with GCC 13.

Step 2: get the source

git clone https://review.coreboot.org/coreboot
cd coreboot

Code review happens on the project's Gerrit instance. The GitHub mirror is read only, and coreboot does not accept GitHub pull requests.

Step 3: build the coreboot toolchain

make help_toolchain
make crossgcc-i386 CPUS=$(nproc)

The i386 toolchain is used for all x86 platforms, including x86_64. The tutorial explains why coreboot ships its own cross compiler: host toolchains vary too much, so using the system compiler is possible but "the results are not reproducible, and may have issues." For audit work, reproducibility is the property you want, so stay on the coreboot toolchain.

Step 4: build a payload

The tutorial uses coreinfo, a small demonstration payload that shows memory and CBFS contents:

make -C payloads/coreinfo olddefconfig
make -C payloads/coreinfo

Step 5: configure with Kconfig

make menuconfig

Choose Mainboard vendor "(Emulation)" and model "QEMU x86 i440fx/piix4". Under Payload, choose "An ELF executable payload" and set the path to payloads/coreinfo/build/coreinfo.elf. Kconfig is the same configuration system the Linux kernel uses. Two habits from the tutorial save hours: run make distclean whenever you change mainboards, because Kconfig otherwise carries values over into a hybrid configuration, and save a minimal configuration you can review and commit:

make savedefconfig
cat defconfig

Step 6: build and inspect the image

make
ls -l build/coreboot.rom

At the end of the build, coreboot prints the contents of the image. You can list CBFS at any time with cbfstool, which is built in util/cbfstool:

util/cbfstool/cbfstool build/coreboot.rom print

Step 7: boot it in QEMU

qemu-system-x86_64 -bios build/coreboot.rom -serial stdio

The coreboot log appears on the serial console and the coreinfo payload opens in a window.

Step 8: before flashing real hardware

Warning: the commands that follow change your firmware flash chip. A wrong image, the wrong board or an interrupted write can leave a machine that will not power on until the chip is reprogrammed externally.

Do these checks first, every time:

1. Confirm the board identity. Compare the exact model and revision against the coreboot mainboard you built for. Variants with the same marketing name can have different flash sizes or EC firmware.

   sudo dmidecode -s system-manufacturer
   sudo dmidecode -s system-product-name
   sudo dmidecode -s baseboard-product-name
   

2. Confirm flashrom sees the right chip. Running flashrom with only the programmer and no operation probes and prints the detected chip and size. Stop if it finds no chip, more than one chip, or a size that does not match your image.

   sudo flashrom -p internal
   ls -l build/coreboot.rom
   

3. Check write protection. --wp-status prints the chip's status register protection mode and protected range.

   sudo flashrom -p internal --wp-status
   

4. Take two backups and compare them. A single read can be corrupted. If the two hashes differ, do not continue.

   sudo flashrom -p internal -r backup1.rom
   sudo flashrom -p internal -r backup2.rom
   sha256sum backup1.rom backup2.rom
   

   Copy the backup off the machine you are about to flash.
5. Have an external programmer and clip ready, and know where the flash chip is on the board. The coreboot FAQ says the first thing anyone porting a board needs is "a method to recover your system from a failed flash."

Step 9: write only the region you mean to change

On Intel systems the flash is divided by the flash descriptor into regions: fd, bios, me, gbe and pd, according to the flashrom manual. The coreboot FAQ recommends that first time users flash coreboot "to the BIOS region and leaving the remaining regions untouched." flashrom's --ifd reads the layout from the on chip descriptor and -i limits the operation to named regions.

Warning: this overwrites firmware. Re-run the identity, chip detection and backup checks above in the same session, immediately before this command, and do not flash on battery alone or during a storm.

# Re-check: correct board, correct chip, verified backups saved elsewhere
sudo dmidecode -s system-product-name
sudo flashrom -p internal

# Write only the BIOS region, then verify it
sudo flashrom -p internal --ifd -i bios -w build/coreboot.rom
sudo flashrom -p internal --ifd -i bios -v build/coreboot.rom

On a coreboot image with a flash map (FMAP), flashrom can read the layout from the chip instead. The flashrom manual gives this example for updating only the COREBOOT region:

sudo flashrom -p internal --fmap -i COREBOOT -w build/coreboot.rom

If anything goes wrong during a write, the flashrom project's first instruction is: "do NOT turn off/reboot your computer." Ask for help on the project's IRC, Discord or mailing list while the system is still running, because a running system can often still be rewritten.

Step 10: confirm measured boot after boot

If you built with measured boot, check what the firmware recorded. The coreboot measured boot page gives these commands:

# Dump the TPM event log coreboot recorded
sudo cbmem -L

# Hash a CBFS file in your image the same way coreboot does
cbfstool coreboot.rom extract -r COREBOOT -n fallback/romstage -U -f /dev/stdout | sha256sum

# Hash a flash map region, such as the ME region
cbfstool coreboot.rom read -n SI_ME -f /dev/stdout | sha256sum

If a hash in the event log does not match the hash of the file in the image you think you flashed, you are not running that image.

How do firmware updates and recovery work?

There are three update paths on coreboot systems, and which one you get depends on who built the firmware.

flashrom

flashrom is the general purpose tool. Its README describes it as a utility for "identifying, reading, writing, verifying and erasing flash chips," supporting more than 627 flash chips, 407 chipsets and 539 mainboards at the time we read it. It can write in a running system over SSH, needs only root for the internal programmer, and is scriptable, which is why fleets of identical machines are often reflashed with it. The manual warns that internal programmer support on Windows is not available, so in practice this is a Linux or BSD tool.

fwupd and LVFS

The LVFS documentation describes the Linux Vendor Firmware Service as "a secure web service that can be used by OEM's to upload firmware archives" and that users query for update metadata. fwupd on the device works out what hardware and firmware versions are present and applies updates through a standard mechanism such as UEFI UpdateCapsule. Several coreboot distributions use this path. Dasharo's documentation includes guides for UEFI capsule updates and fwupd based updates, and the coreboot distributions page lists a laptop maker shipping Dasharo with security updates through fwupd. Our post on firmware updates on Linux with fwupd and LVFS covers the capsule update flow in detail.

vboot A and B slots

On ChromeOS devices the OS updates the inactive read/write slot and the firmware decides which slot to trust, as described above. The read only region and recovery firmware are not touched in the field.

Recovery

flashrom supports many external programmers, including USB to SPI adapters such as the CH341A based ch341a_spi and debug probes such as jlink_spi. The coreboot FAQ warns that boards with two flash chips are harder to reflash externally and that some laptops are "notoriously sensitive" to external reflashing, so read your board's page in the coreboot docs before buying hardware.

The Chromium recovery design adds a principle worth copying: recovery firmware should not need network access, because recovery media is built on a second, networked computer.

How do Dasharo, LinuxBoot and the open source firmware movement fit?

Dasharo

Dasharo describes itself as "an open-source firmware distribution" focused on trustworthiness, privacy and liberty. It is built on coreboot, usually with an edk2 payload, and documents supported boards, PCR measurements, flash regions, capsule and fwupd updates and its test specifications. For most organizations a distribution like this is the practical way to run coreboot: someone else tracks upstream, validates releases on specific boards and ships updates through standard tooling.

LinuxBoot

LinuxBoot is "the concept of using a Linux kernel and initramfs as a bootloader." It is a Linux Foundation project with a technical charter. The project's site says its build system started as NERF at Google in January 2017, targeting servers and PCs, and lists reasons to use it: hardened Linux drivers instead of lightly tested firmware drivers, a faster boot by removing unnecessary code, and an initramfs that can carry site specific drivers and tools. LinuxBoot can run as a coreboot payload, which is the coreboot docs' "Linux as a payload" case. That puts a full Linux kernel and userland in your firmware, so your firmware now has a Linux patch cycle too.

The Open Source Firmware Foundation

The Open Source Firmware Foundation describes itself as uniting "developers, companies, and communities to create secure, transparent, and flexible firmware solutions." It runs the Open Source Firmware Conference (OSFC 2026 is listed as upcoming on its site) and highlights projects including coreboot, barebox, u-bmc and the USB armory. It is a community umbrella, not a certification body.

What does open firmware change for audits?

Proprietary firmware leaves an auditor with a vendor statement and a version number. Open firmware gives you three more things, each with limits.

You can rebuild and compare

With the source, the Kconfig defconfig and the coreboot toolchain, you can rebuild an image and compare it with the one on the chip. The coreboot tutorial's warning that system toolchains are "not reproducible" is a reminder that this only works if you use the project toolchain and pin every input, including payload commits and blob versions. Heads makes reproducible ROMs an explicit goal.

The image can carry its own SBOM

Coreboot can embed a software bill of materials in CBFS. The coreboot SBOM documentation explains that it uses uSWID, a container holding multiple CoSWID tags (the CBOR form of ISO SWID, specified as an RFC), so relationships such as "FSP is included as a dependency of coreboot" can be expressed. A tool called goswid links per component tags into one sbom.uswid file in CBFS. Each component has CONFIG_INCLUDE_<name>_SBOM and CONFIG_SBOM_<name>_PATH options, and some have CONFIG_SBOM_<name>_GENERATE to extract basic data. For payloads, the commit hash used in the build is recorded automatically.

The documentation is frank about the weak spot: the default tags hold "very little information or even worse wrong information," and extracting data from closed blobs is hard. It recommends that blob vendors produce SBOM files in their own builds. If you use this feature, set the path options to real tags and review them.

You can map controls to NIST guidance

NIST SP 800-147 (April 2011) covers protecting BIOS firmware on PC clients from unauthorized modification, including authenticated updates. SP 800-193 (May 2018) broadens that to platform firmware resiliency, organized around protecting firmware, detecting unauthorized changes and recovering "rapidly and securely." Coreboot features map onto those goals fairly directly:

What open firmware does not give you

Open source coreboot code does not open the FSP, the microcode, or the ME and PSP firmware. Your audit boundary should say so explicitly: "we reviewed and rebuilt coreboot and the payload; the following vendor binaries, by hash and version, are trusted on the vendor's word." Our post on what a firewall cannot see in firmware, BMCs and management engines explains why those components still matter.

The project is hardening its own parsers

The coreboot 26.09 notes describe a cycle focused on "hardening and refining the existing codebase": stricter EDID, device tree, BMP, CBFS and FMAP parsing, TPM2 response size checks, and a new SPD_CACHE_TPM_HASH option that keeps a SHA-256 of the memory SPD cache in TPM NVRAM and forces retraining if writable flash was changed. Ask your distribution how quickly it picks up changes like these.

Common mistakes

• Assuming coreboot means no blobs. On current Intel and AMD client hardware it almost never does. Write down every binary in your image and its version.
• Expecting UEFI style PCRs. Coreboot puts nearly all firmware measurements in PCR 2 and leaves PCRs 4 to 7 empty. Disk encryption policies and attestation baselines built for UEFI machines will not match.
• Flashing the whole chip on a first install. Writing the full image also rewrites the descriptor, ME and GbE regions. Start with the BIOS region only, as the coreboot FAQ recommends.
• Skipping the second backup read. One corrupted read becomes your only recovery image.
• Rebooting after a failed write. flashrom's own advice is to keep the machine running and ask for help.
• Building with the system compiler for production. It works, but the coreboot docs say the result is not reproducible, which defeats the audit benefit.
• Stripping the ME to "remove" it. The coreboot project does not recommend modifying ME firmware, and partial removal can leave it in an error state of unknown security.
• Leaving write protection off after development. vboot's recovery promise depends on the read only region staying read only.
• Keeping default SBOM tags. The coreboot docs warn that the defaults can be thin or wrong.

FAQ

Is coreboot better than UEFI for security?

It depends on what you measure. Coreboot has less code, is open for review and can be rebuilt, and it supports verified and measured boot. But modern boards still run closed vendor blobs alongside it, and UEFI features such as Secure Boot only exist if you add an edk2 payload. The security gain is mostly in auditability and in removing code you do not need.

Can I install coreboot on any laptop?

No. Your CPU and chipset must be supported, your exact board needs a port, and features such as Intel Boot Guard can block coreboot entirely. Check the mainboard list with make menuconfig or the board status page, and confirm Boot Guard status with intelmetool -b where supported.

Do Chromebooks use coreboot?

Yes. The coreboot documentation says all ChromeOS devices released from 2012 onward use coreboot as their main system firmware, with depthcharge as the payload and Google's verified boot.

Does coreboot remove the Intel Management Engine?

No. The ME is a separate processor whose firmware shares the flash chip. Coreboot does not control it. Some distributions set the HAP bit to put it into a disabled debug state, and the coreboot project advises against further modification.

Does coreboot support Secure Boot?

Coreboot itself provides vboot, its own signature based verified boot. UEFI Secure Boot comes from the edk2 payload, and you manage its keys the same way you would on any UEFI machine.

How do I update coreboot firmware?

Use whatever path your firmware supplier supports: fwupd and LVFS or UEFI capsules for distributions that publish them, the vboot A and B slot mechanism on ChromeOS, or flashrom with a verified image and backups for self built firmware.

How do I recover from a bad coreboot flash?

If the system is still running, do not reboot; try rewriting with flashrom. If it will not start, connect an external SPI programmer to the flash chip and write your saved backup. On vboot systems, recovery mode from the read only region can restore the read/write slots.

What is the difference between coreboot and Libreboot?

Libreboot is a downstream coreboot distribution that ships ready made images only for boards that can be built entirely from source, so its tree excludes boards that need binary components. Coreboot itself supports those boards too.

Where Safeguard fits

Safeguard does not scan firmware images, flash chips or the binary blobs in them, and it does not verify boot measurements. The fit is with the software around firmware. A coreboot build is a git tree with submodules, payloads pulled from other open source projects, a LinuxBoot initramfs that may carry Go and C userland tools, build containers and the scripts your team writes to sign and roll out images. Those are ordinary source repositories and container images, and their open source dependencies need the same patch discipline as any other code you ship.

Firmware projects are built from open source parts like any other software: payloads, build tooling, signing scripts and the containers that run them all pull in dependencies that get CVEs. The fit here is indirect, since the steps below cover the code you build and ship, not the vendor blobs or the flash chip itself.

Fix it without waiting for upstream

Whatever the vulnerability, most of the risk sits in two gaps. The first is the time between a fix being published and that fix actually running in your production builds. The second, and worse, is the time before any fix exists at all, while a maintainer works out a patch and a release schedule. Waiting through both gaps is a habit, not a requirement. Safeguard gives teams three ways to close them.

1. Autonomous remediation: pull requests, not tickets

When a fixed version exists, Safeguard's Griffin models open a tested, policy gated pull request that moves the affected dependency to the safe version. You can run it on one repository or in bulk across every project that carries the vulnerable version. Remediation covers eight categories, including dependencies, licenses, security posture and findings. Reachability analysis ranks the vulnerable code paths your application actually calls first, so the first pull requests you merge are the ones that matter most. Autonomous remediation ships switched off, with every category set to Manual, so your team decides how much runs on its own and what still needs a human approval.

2. Gold Open Source: the safe version in seconds, free

gold.safeguard.sh is free and needs no login. Search any CVE or package to see affected and fixed versions, CVSS, EPSS, CISA KEV status and a recommended safe version, or use the "Am I affected?" checker. The same data is available through a free read API, README status badges and RSS threat feeds. The safeguard-sh/gold-scan-action GitHub Action can fail a build on a known exploited vulnerability, on any known vulnerability, or never, so a version you have just removed cannot quietly come back in next week's merge.

3. Gold Registry: start from components that are already fixed

registry.safeguard.sh provides hardened, drop in replacements for upstream packages and container images. Every Gold artifact is held continuously to zero exploitable critical or high CVEs, zero malware and a completed license check, with SLSA L3 or higher provenance, a Sigstore signature and a public evidence page you can hand to an auditor. An artifact loses its Gold badge if it regresses. Teams can point their own package directory at the registry so hardened equivalents resolve without changing how developers install anything.

When upstream has no fix yet, or will not ship one, Safeguard first works to get the fix accepted upstream. If the issue is severe or upstream will not move, Safeguard builds a fork, fixes the vulnerability there and publishes a hardened Gold build, so you are not stuck on a maintainer's release schedule. You can also request a hardened, compatibility tested build of a specific package. This fork and patch flow is in early access today, so ask which packages it covers before you plan around it.

One honest limit: when the vulnerable code lives in a vendor appliance, a hosted service or an operating system runtime you do not build yourself, the fix still has to come from that vendor or distribution. The steps above apply to the open source dependencies and container images you build and ship, which is where most teams carry the largest and least tracked share of their exposure.

See how Safeguard would help

The demos below show Safeguard on ordinary software projects, not on firmware images. They apply to the repositories around a coreboot deployment: the build container, the signing and rollout scripts, and any LinuxBoot userland you maintain. Safeguard can scan those with safeguard scan --dir ., --image for a container image, or --sbom for an SBOM file you already have, and it writes results as JSON under ./output.

The first demo is a real Safeguard CLI session. After install, safeguard opens the interactive terminal, you ask it to fix the lodash CVE in a repository, and it reads the finding and advisory, asks before each command, edits package.json to lodash 4.17.21, runs npm install and npm test with your approval, prints a summary and pushes nothing. It ends with /permissions, /model and /scan. The same ask, approve and test loop applies to a firmware tooling repository where you want every change reviewed before it runs.

Click through it at your own pace, or open it full screen.

Firmware signing and build machines are often kept off the general network. The local runner demo shows how to set up the runner on your own machine, approve it with its device code, and then scan from the terminal. A runner on a build host can scan the build tree and containers that live there.

Click through it at your own pace, or open it full screen.

If your team uses Claude, the third demo shows how to connect Claude to the Safeguard MCP server with OAuth and choose which tools Claude can use. An engineer can then ask about known vulnerabilities in the projects that hold your firmware build and rollout tooling, using only the tools you allowed.

Click through it at your own pace, or open it full screen.

To try it on your own repositories, download Safeguard and follow the CLI documentation.

Quick check

Sources

• coreboot documentation: coreboot architecture (stages)
• coreboot documentation: Payloads
• coreboot documentation: Tutorial part 1, starting from scratch
• coreboot documentation: vboot, Verified Boot Support
• coreboot documentation: Measured Boot
• coreboot documentation: FAQ
• coreboot documentation: Distributions
• coreboot documentation: Software Bill of Materials
• coreboot documentation: Release notes index
• coreboot 26.09 release notes
• coreboot source tree: README.md
• coreboot source tree: Documentation/index.md
• Ron Minnich, "Welcome to coreboot", coreboot mailing list, 12 January 2008 (archived)
• Chromium OS design docs: Verified Boot
• Chromium OS design docs: Firmware Boot and Recovery
• LinuxBoot project
• flashrom README
• flashrom manual page
• LVFS documentation: Introduction
• Dasharo documentation
• Open Source Firmware Foundation
• NIST SP 800-147, BIOS Protection Guidelines (April 2011)
• NIST SP 800-193, Platform Firmware Resiliency Guidelines (May 2018)

Last reviewed: 23 October 2026. Coreboot board support, blob requirements and Kconfig options change between releases; check the documentation for the release and mainboard you build.