You press the power button. You see your manufacturer’s logo. You wait for your operating system.

You are already running an operating system.

UEFI — the Unified Extensible Firmware Interface — is not a simple BIOS. It is a complete operating system with drivers, a network stack, a shell, and more privilege than your kernel will ever have.

It runs before you. It runs below you. It can brick your hardware with a single bad write.

What UEFI Actually Is:

Component	Present in UEFI
Boot manager	Yes
Filesystem drivers	Yes (FAT32, sometimes NTFS, ext4)
Network stack	Yes (TCP/IP, HTTP, TLS)
Graphics drivers	Yes (GOP - Graphics Output Protocol)
USB stack	Yes
Shell	Yes (full command line)
Application loader	Yes (runs .efi executables)
Variable storage	Yes (NVRAM, persistent)
Secure Boot	Yes (cryptographic verification)
TPM integration	Yes

Your BIOS from 1990 initialized hardware and jumped to a boot sector. That was it.

UEFI is 16-32MB of code. It can browse the web. It can download executables. It runs with Ring 0 (and below) privilege.

This is not firmware. This is an operating system pretending to be firmware.

The UEFI Shell:

Press the right key at boot, and you get a shell:

Shell> fs0:
FS0:\> ls
Directory of: FS0:\
  EFI        <DIR>
  boot.efi   1,234,567

FS0:\> edit startup.nsh
FS0:\> bcfg boot dump

A full command-line environment. File operations. Text editing. Boot configuration. Network commands.

This shell runs before your operating system. This shell has complete hardware access. This shell can modify your boot process.

EFI Variables: The Bricking Mechanism

UEFI stores configuration in NVRAM — non-volatile RAM that persists across reboots:

# Linux: list all EFI variables
ls /sys/firmware/efi/efivars/

# Example variables:
Boot0001-8be4df61-...    # Boot entry
SecureBoot-8be4df61-...  # Secure Boot state
PK-8be4df61-...          # Platform Key

These variables control:

• Boot order
• Secure Boot keys
• Hardware configuration
• Manufacturer settings

And they can brick your system.

In 2016, running rm -rf / on certain Linux systems deleted EFI variables. The motherboard would not boot. The hardware was permanently damaged by deleting files.

# DO NOT RUN THIS
rm -rf /sys/firmware/efi/efivars/*
# Congratulations, your motherboard is now garbage

The firmware depends on certain variables existing. Delete them, and the firmware cannot function. Some motherboards have no recovery mechanism.

Your operating system can brick your hardware by deleting the wrong files. This is not a bug. This is UEFI working as designed.

Secure Boot: Microsoft’s Keys

Secure Boot verifies that boot code is signed before execution. Good concept. Problematic implementation.

The default keys in most UEFI implementations:

1. Microsoft’s keys — Always present
2. Manufacturer’s keys — Sometimes present
3. Your keys — Not present unless you add them

To boot unsigned code (like a custom kernel), you must:

1. Disable Secure Boot entirely, or
2. Add your own keys and sign your bootloader

Adding your own keys requires entering the UEFI setup, navigating obscure menus, and hoping your manufacturer implemented key management correctly.

Many manufacturers didn’t.

The Secure Boot Bypass History:

Year	Vulnerability
2012	Secure Boot disabled by default on many systems
2014	”Boot Hole” - GRUB vulnerability bypassed Secure Boot
2016	Golden Key leak - Microsoft’s test keys leaked
2020	”Boot Hole 2” - More GRUB vulnerabilities
2022	”Black Lotus” - First UEFI bootkit in the wild
2024	PKfail - Hundreds of devices shipped with test keys

Secure Boot has been bypassed repeatedly. The complexity of UEFI creates endless attack surface. Each bypass requires new signatures, new blocklists, new complexity.

HTTP Boot: Yes, Really

UEFI can boot from HTTP:

FS0:\> ifconfig -s eth0 dhcp
FS0:\> connect http://server/boot.efi

Your firmware can download and execute code from the network. Before your operating system. Before your firewall. Before any security software.

The specification calls this a feature. Security researchers call this an attack vector.

The UEFI Boot Process:

flowchart TD
    SEC["SEC<br/>Security Phase"]
    PEI["PEI<br/>Pre-EFI Init"]
    DXE["DXE<br/>Driver Execution"]
    BDS["BDS<br/>Boot Device Selection"]
    TSL["TSL<br/>Transient System Load"]
    RT["RT<br/>Runtime Services"]
    OS["Your OS<br/>Finally"]

    SEC -->|"Init temp RAM<br/>Verify PEI"| PEI
    PEI -->|"Init RAM<br/>Discover HW"| DXE
    DXE -->|"Load drivers<br/>Init devices"| BDS
    BDS -->|"Read boot vars<br/>Find media"| TSL
    TSL -->|"Load bootloader"| OS
    RT -.->|"Still running<br/>below you"| OS

    style SEC fill:#450a0a,stroke:#dc2626
    style PEI fill:#7f1d1d,stroke:#dc2626
    style DXE fill:#991b1b,stroke:#dc2626
    style BDS fill:#b91c1c,stroke:#dc2626
    style TSL fill:#dc2626,stroke:#fca5a5
    style RT fill:#450a0a,stroke:#fca5a5,stroke-width:2px,stroke-dasharray: 5 5
    style OS fill:#334155,stroke:#94a3b8

Five phases before your operating system. Each phase has drivers. Each driver has code. Each line of code is attack surface.

Runtime Services: UEFI Never Leaves

Even after your OS boots, UEFI remains:

// OS can call UEFI runtime services
EFI_STATUS status = gRT->GetVariable(
    L"BootOrder",
    &gEfiGlobalVariableGuid,
    NULL,
    &size,
    &data
);

Your kernel calls back into UEFI code. UEFI code runs with SMM (System Management Mode) privilege — Ring -2, below your kernel.

UEFI is not a bootloader that exits. UEFI is a hypervisor that pretends to leave.

The SMM Problem:

System Management Mode is a CPU mode more privileged than Ring 0:

graph TB
    subgraph "CPU Privilege Rings"
        R3["Ring 3: User Apps"]
        R0["Ring 0: Kernel"]
        R1["Ring -1: Hypervisor"]
        R2["Ring -2: SMM ← UEFI"]
        R3M["Ring -3: Intel ME"]
    end

    R3 --> R0
    R0 --> R1
    R1 --> R2
    R2 --> R3M

    style R3 fill:#334155,stroke:#94a3b8
    style R0 fill:#7f1d1d,stroke:#dc2626
    style R1 fill:#991b1b,stroke:#dc2626
    style R2 fill:#b91c1c,stroke:#fca5a5,stroke-width:3px
    style R3M fill:#450a0a,stroke:#dc2626

SMM code:

• Cannot be debugged by the kernel
• Cannot be inspected by the kernel
• Has full access to system memory
• Handles power management, thermal events, etc.

UEFI installs SMM handlers. These handlers run during your OS execution. You cannot see them. You cannot audit them.

UEFI Malware:

UEFI’s persistence makes it perfect for malware:

Malware	Year	Capability
Hacking Team	2015	UEFI rootkit for surveillance
LoJax	2018	First in-the-wild UEFI rootkit
MosaicRegressor	2020	Nation-state UEFI implant
ESPecter	2021	EFI System Partition bootkit
Black Lotus	2022	Bypasses Secure Boot, $5000 on forums
CosmicStrand	2022	UEFI firmware rootkit

Reinstall your OS? Malware survives. Replace your hard drive? Malware survives. It lives in flash, below everything you can touch.

What Can You Do:

1. Enable Secure Boot — Imperfect but raises the bar
2. Set a UEFI password — Prevents casual modification
3. Disable network boot — Unless you need it
4. Update UEFI firmware — Patches exist (sometimes)
5. Use Coreboot — If your hardware supports it
6. Monitor EFI System Partition — Changes indicate tampering
7. Use measured boot with TPM — Detect modifications

None of these are complete solutions. UEFI is too complex. The attack surface is too large.

The Comparison:

Aspect	Legacy BIOS	UEFI
Size	~256KB	16-32MB
Complexity	Low	Extreme
Network capable	No	Yes
Attack surface	Small	Massive
Secure Boot	No	Yes (imperfect)
Can brick hardware	Rarely	Yes
Runs during OS	No	Yes (runtime services)

We replaced a simple bootloader with an operating system. We gained features. We lost simplicity. We created an attack surface that cannot be fully secured.

The Lesson:

UEFI was designed by committee. Intel, Microsoft, HP, and others wanted features. They got features. They also got 16MB of attack surface running below every operating system.

Your carefully hardened kernel runs on top of UEFI. Your firewall protects traffic that UEFI could intercept before it loads. Your antivirus scans files while UEFI rootkits laugh from Ring -2.

The firmware is the foundation. A compromised foundation means a compromised everything.

UEFI is not your BIOS. UEFI is an operating system you never installed, never configured, and cannot fully audit.

It runs first. It runs always. It runs below.

Welcome to the layer beneath your operating system.

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