When you press the power button, what runs first?

Not your operating system. Not your bootloader. Not even U-Boot.

Firmware runs first. And you do not control it.

Your BIOS — now called UEFI — is megabytes of proprietary code written by your motherboard vendor. You cannot read it. You cannot audit it. You cannot modify it.

You trust it completely because you have no choice.

Coreboot gives you a choice.

The UEFI Problem:

Modern UEFI firmware is not a simple “BIOS.” It is an operating system:

UEFI Component	Function
DXE Core	Driver execution environment
SMM	System Management Mode (Ring -2)
Network Stack	Yes, your BIOS has TCP/IP
HTTP Boot	Download and execute code from network
Secure Boot	Microsoft controls the keys
UEFI Shell	Full command-line environment
Graphics	GUI setup menus
Bluetooth	Some implementations

Your UEFI firmware is 16-32MB of code running before your operating system. It includes network drivers, graphics drivers, USB stacks, and filesystem support.

This is not a BIOS. This is an attack surface you cannot inspect.

What Coreboot Is:

Coreboot (formerly LinuxBIOS) is open-source firmware. You compile it. You flash it. You own it.

UEFI Boot:
Power On → UEFI (16MB, proprietary) → Bootloader → OS

Coreboot Boot:
Power On → Coreboot (~1MB, open source) → Payload → OS

Coreboot does the minimum:

1. Initialize RAM
2. Initialize enough hardware to load a payload
3. Hand off to payload

The payload can be:

• SeaBIOS — Legacy BIOS compatibility
• TianoCore — Open source UEFI implementation
• GRUB — Direct to bootloader
• Linux — Boot kernel directly as payload
• U-Boot — For ARM/embedded
• Heads — Security-focused, tamper-evident boot

Coreboot is small because it does less. Less code means fewer bugs. Fewer bugs means fewer vulnerabilities. This is not a limitation. This is the point.

The Boot Flow:

1. Reset Vector
   CPU starts executing at 0xFFFFFFF0

2. Bootblock
   Coreboot's first stage (~32KB)
   Cache-as-RAM initialization
   Finds and loads romstage

3. Romstage
   DRAM initialization
   Memory training
   Loads ramstage

4. Ramstage
   Full hardware initialization
   PCI enumeration
   ACPI table generation
   Loads payload

5. Payload
   SeaBIOS, GRUB, Linux, or Heads
   Boots your operating system

Four stages, all open source. Each stage you can read, modify, compile, and verify.

Supported Hardware:

Coreboot does not support every motherboard. It supports motherboards where:

• The chipset is documented (or reverse-engineered)
• The CPU initialization is understood
• Someone did the porting work

Vendor	Status
Chromebooks	Full support (Google funds Coreboot)
System76	Ships Coreboot (Open Firmware)
Purism	Ships Coreboot (Librem laptops)
Lenovo ThinkPads	Community ports (X200, X230, T440p, etc.)
AMD Desktops	Growing support
Intel Desktops	Some support, ME complicates things
NovaCustom	Ships Coreboot (European vendor)
Starlabs	Ships Coreboot

Chromebooks run Coreboot because Google wanted control over the boot process. If Google trusts open-source firmware, perhaps you should question why you trust proprietary firmware.

The Intel ME Problem (Again):

Coreboot replaces your BIOS. It does not replace Intel Management Engine.

The ME runs on a separate processor. It initializes before the main CPU. It is not part of the BIOS — it is part of the chipset.

However, Coreboot enables me_cleaner integration:

# me_cleaner removes non-essential ME modules
python me_cleaner.py -S -O modified_me.bin original_me.bin

# Flash modified ME alongside Coreboot
# ME still initializes hardware, but surveillance modules removed

You cannot fully remove ME on modern Intel. But you can lobotomize it. Coreboot makes this easier.

On AMD, Platform Security Processor (PSP) presents similar challenges. AMD has been slightly more cooperative with documentation. Slightly.

Heads: Tamper-Evident Boot:

Heads is a Coreboot payload focused on security:

Heads provides:
- TPM-based measured boot
- TOTP verification (your laptop proves its identity to YOU)
- Signed boot verification
- USB security key integration
- Detection of firmware tampering

Normal boot: You trust the laptop. Heads boot: The laptop proves it has not been tampered with.

With Heads, if someone modifies your firmware while you sleep, your TOTP code will not match. The laptop fails to authenticate itself. You know you have been compromised.

This inverts the trust model. The hardware must prove itself worthy of your secrets.

Building Coreboot:

# Clone repository
git clone https://review.coreboot.org/coreboot.git
cd coreboot

# Get submodules
git submodule update --init --checkout

# Configure for your board
make menuconfig
# Select: Mainboard → [Vendor] → [Model]
# Select: Payload → SeaBIOS (or Heads, TianoCore, etc.)

# Build toolchain (first time only)
make crossgcc-i386 CPUS=$(nproc)

# Build firmware
make -j$(nproc)

# Output: build/coreboot.rom

Then flash with internal programmer (if supported) or external SPI programmer.

Warning: Flashing firmware incorrectly bricks your machine. External programmer (CH341A, Bus Pirate) recommended for recovery capability.

The Blob Situation:

“Blob” = Binary Large Object. Proprietary code required for hardware initialization.

Component	Open Source?
Coreboot core	Yes
Intel FSP (Firmware Support Package)	No — required for modern Intel
AMD AGESA	Partially — AMD provides binaries
Intel ME	No — cannot be fully removed
AMD PSP	No — cannot be fully removed
VGA BIOS	Sometimes — SeaVGABIOS for some cards
EC Firmware	Varies — some laptops have open EC

Coreboot is open source. Some hardware initialization still requires blobs. This is not Coreboot’s failure — this is hardware vendors refusing to document their silicon.

Blame Intel. Blame AMD. Coreboot works around them as much as possible.

Why This Matters:

Your operating system can be secure. Your bootloader can be verified. Your kernel can be signed.

None of this matters if your firmware is compromised.

UEFI firmware has had vulnerabilities. Bootkits exist. ThinkPwn, Hacking Team UEFI rootkits, LoJax — all targeted firmware because firmware is game over.

If attackers control your firmware, they control everything above it. Your operating system cannot detect firmware compromise. Your antivirus cannot scan firmware. Your encryption keys pass through compromised firmware.

Coreboot is not perfect. But Coreboot is auditable. When vulnerabilities are found, you can read the fix. You can verify the fix. You can compile the fix yourself.

Proprietary UEFI vulnerabilities are fixed when the vendor feels like it. If ever.

The Pyongyang Firmware Initiative:

All critical systems run Coreboot where hardware permits.

• ThinkPads: Coreboot with Heads payload
• Servers: Coreboot where supported, isolated VLANs where not
• Chromebooks: Already Coreboot, repurposed
• Custom hardware: From silicon to firmware to OS, controlled

We cannot eliminate all blobs. Intel refuses documentation. But we minimize proprietary code, audit what we can, and isolate what we cannot.

The firmware is the foundation. A compromised foundation collapses everything built above.

What You Should Do:

1. Check Coreboot compatibility — Does your hardware have a port?
2. Buy Coreboot-compatible hardware — System76, Purism, NovaCustom, Starlabs, used ThinkPads
3. Learn to flash firmware — SPI programmers are cheap insurance
4. Consider Heads — Tamper-evident boot is worth the complexity
5. Support Coreboot development — Documentation comes from reverse engineering. Reverse engineering needs funding.

The Lesson:

UEFI is 16MB of code you did not write, cannot read, and must trust.

Coreboot is ~1MB of code you can clone, audit, modify, compile, and flash.

The choice is philosophical: Do you own your hardware, or does your hardware own you?

Your BIOS runs first. Your BIOS sees every secret. Your BIOS could betray you before your operating system even loads.

Own your firmware. Compile your BIOS. Trust nothing you cannot audit.

Coreboot is the escape from the blob. Take it.

— Kim Jong Rails, Supreme Leader of the Republic of Derails