Boot Process

Press the power button on any computer, and you initiate a remarkable transformation. One moment, you have a collection of inert components—transistors holding no charge, capacitors discharged, memory cells in random states. A fraction of a second later, electrical signals begin propagating through billions of pathways, and sophisticated software begins executing instructions that have been waiting, frozen in non-volatile storage, for exactly this moment.

This transformation doesn't happen by magic. It's orchestrated by firmware—the foundational software layer that bridges raw hardware and the operating system. Without firmware, an operating system would have no way to discover what hardware exists, no way to initialize it into a usable state, and no way to load itself into memory.

The firmware that performs this critical role has evolved dramatically over four decades, from the simple BIOS (Basic Input/Output System) designed for the first IBM PC to the sophisticated UEFI (Unified Extensible Firmware Interface) that powers modern systems. Understanding both is essential for any systems engineer.

When a computer powers on, it faces a profound bootstrapping problem: the CPU needs instructions to execute, but all normal storage (RAM) is empty or contains garbage. The solution is firmware—software permanently stored in non-volatile memory that provides the initial instructions the CPU needs.

The Cold Boot Challenge:

At power-on, the system is in a primitive state:

• RAM contains random bit patterns (not zeroed)
• CPU registers are in undefined states (except the reset vector)
• Caches are invalid and disabled
• Peripheral devices are uninitialized and unconfigured
• Storage devices may need initialization sequences before they can be read

The firmware's job is to transform this chaos into order—to perform Power-On Self-Test (POST), initialize hardware, discover boot devices, and transfer control to the operating system's bootloader.

Firmware Storage:

Firmware resides in flash memory chips on the motherboard (historically, ROM or EEPROM). This non-volatile storage retains content without power, ensuring firmware is always available at boot. Modern systems also store configuration data (boot order, hardware settings) in battery-backed NVRAM or flash storage.

The firmware executes directly from this flash storage initially (Execute-In-Place or XIP), then typically copies itself to RAM for faster execution once memory is initialized. This copy-to-RAM operation is called shadowing.

The BIOS (Basic Input/Output System) originated with the IBM PC in 1981 and remained the dominant firmware architecture for over three decades. Despite its age, understanding BIOS is essential—many concepts carry forward to UEFI, legacy systems remain in production, and BIOS remains a common interview topic.

Historical Context:

The original IBM PC BIOS was designed when:

• Systems had 64KB to 640KB of RAM
• Storage meant floppy disks and small hard drives (<10MB)
• CPUs operated in 16-bit real mode
• Security threats were minimal (no networks, no malware industry)

These constraints shaped BIOS into a simple, 16-bit system with severe limitations that would haunt PC architecture for decades.

The BIOS Boot Sequence:

1. CPU Reset — CPU begins executing at reset vector, which points to firmware ROM
2. POST Execution — Verify CPU, memory controller, RAM (often with characteristic counting display)
3. Device Initialization — Initialize video, keyboard, storage controllers
4. Option ROM Scan — Execute firmware extensions on add-in cards (network boot ROMs, RAID controllers)
5. Boot Device Search — Check configured boot order (floppy, CD-ROM, HDD, network)
6. MBR Load — Read first 512 bytes of boot device into memory at address 0x7C00
7. MBR Execution — Transfer control to loaded boot sector code

The 512-Byte Constraint:

The MBR's 512-byte limit is one of BIOS's most notorious constraints:

• First 446 bytes: Boot code (the actual bootloader first stage)
• Next 64 bytes: Partition table (4 entries × 16 bytes each)
• Final 2 bytes: Boot signature (0x55AA)

No meaningful bootloader fits in 446 bytes, so MBR boot code typically just loads a larger second-stage bootloader from disk—a technique called chain loading.

BIOS provides services to bootloaders and early operating system code through software interrupts. These interrupt handlers, installed by BIOS during initialization, offer standardized interfaces for hardware access without requiring knowledge of specific hardware details.

The Interrupt Vector Table (IVT):

In real mode, the first 1024 bytes of memory (addresses 0x0000-0x03FF) contain the Interrupt Vector Table—256 entries of 4 bytes each, where each entry holds a segment:offset pointer to an interrupt handler. BIOS populates this table with pointers to its service routines.

Limitations of BIOS Interrupts:

While BIOS interrupts provided essential abstraction, they suffer from fundamental limitations:

1. 16-bit Real Mode Only — BIOS services are only available in real mode. Once an OS switches to protected mode (32-bit) or long mode (64-bit), BIOS interrupts become unusable. The OS must provide its own drivers.

2. No Parallelism — BIOS operations are synchronous and blocking. Disk reads halt the CPU until complete—no background operations possible.

3. Limited Functionality — BIOS was designed for 1981-era hardware. No native support for USB, no network stack, limited graphics capabilities.

4. CHS vs LBA — Original BIOS used Cylinder-Head-Sector addressing, limiting access to ~8GB. Extended INT 13h added LBA support, but older BIOSes lack it.

5. No Extensibility — Adding new BIOS functions requires modifying firmware ROM—effectively impossible for end users.

UEFI (Unified Extensible Firmware Interface) represents a complete redesign of the firmware layer. Developed initially by Intel as EFI (Extensible Firmware Interface) for Itanium processors, it was later adopted as an industry standard through the UEFI Forum, with contributions from AMD, Apple, Dell, HP, IBM, Lenovo, Microsoft, and others.

UEFI addresses virtually every limitation of legacy BIOS while adding capabilities never possible before:

Core UEFI Improvements:

UEFI Boot Flow:

1. SEC (Security Phase) — Minimal code executes from ROM to initialize the CPU and transition out of the reset state. Establishes initial trusted environment.

2. PEI (Pre-EFI Initialization) — Initialize minimum hardware needed for memory. Discovers and initializes system RAM, which is critical for the next phases.

3. DXE (Driver Execution Environment) — The main UEFI phase. Loads and executes drivers for all system devices. Builds comprehensive system tables. Provides boot services and runtime services.

4. BDS (Boot Device Selection) — Evaluates boot options, presents boot menu if configured, loads the selected OS bootloader.

5. TSL (Transient System Load) — Brief phase where the OS bootloader runs using UEFI boot services.

6. RT (Runtime) — After OS calls ExitBootServices(), boot services terminate but runtime services remain available to the running OS.

GPT (GUID Partition Table) is the modern partitioning scheme designed alongside UEFI to overcome MBR's severe limitations. While GPT is closely associated with UEFI, they are technically independent—GPT disks can boot via legacy BIOS (with limitations), and UEFI can theoretically boot MBR disks.

GPT Structure:

GPT uses a more robust design with redundancy:

1. Protective MBR (LBA 0) — A fake MBR that marks the entire disk as a single partition of type 0xEE (GPT Protective). This prevents legacy tools from misinterpreting GPT disks as empty.

2. Primary GPT Header (LBA 1) — Contains disk GUID, partition entry location, CRC32 checksums for integrity verification.

3. Partition Entry Array (LBA 2-33) — 128 partition entries of 128 bytes each. Each entry contains partition type GUID, unique partition GUID, starting/ending LBA, attributes, and name.

4. Partition Data — The actual partition contents.

5. Backup Partition Entries — Mirror of primary entries at end of disk.

6. Backup GPT Header — Mirror of primary header at last LBA.

UEFI includes a built-in boot manager that provides sophisticated boot option management without requiring a separate bootloader. This represents a fundamental shift from the BIOS model.

Boot Variables:

UEFI stores boot configuration in NVRAM variables—persistent storage that survives reboots. Key variables include:

EFI System Partition Structure:

The ESP contains a standardized directory structure:

/boot/efi/                          (ESP mount point on Linux)
├── EFI/
│   ├── BOOT/
│   │   └── BOOTX64.EFI            (Fallback bootloader path)
│   ├── Microsoft/
│   │   └── Boot/
│   │       └── bootmgfw.efi       (Windows Boot Manager)
│   ├── ubuntu/
│   │   ├── shimx64.efi            (Signed shim for Secure Boot)
│   │   ├── grubx64.efi            (GRUB bootloader)
│   │   └── grub.cfg               (GRUB configuration)
│   └── systemd/
│       └── systemd-bootx64.efi    (systemd-boot loader)

The fallback path \EFI\BOOT\BOOTX64.EFI (or BOOTIA32.EFI for 32-bit, BOOTAA64.EFI for ARM64) is used when no explicit boot entries exist—such as when booting from USB drives or newly installed systems.

Secure Boot is a UEFI feature that prevents execution of unauthorized code during boot. By cryptographically verifying every component in the boot chain, Secure Boot defends against bootkits and rootkits—malware that loads before the operating system and can hide from OS-level security tools.

The Trust Problem:

Legacy BIOS had no mechanism to verify that boot code was legitimate. Malware could:

• Replace the MBR to load first and hide itself
• Modify bootloader files while the OS is offline
• Install persistent backdoors immune to OS reinstallation

Secure Boot addresses this by establishing a chain of trust rooted in firmware.

The Microsoft Key Problem:

Most consumer hardware ships with Microsoft's keys pre-installed because Windows requires Secure Boot certification. This creates a practical reality:

• Windows bootloaders are signed by Microsoft and Just Work™
• Linux distributions must either:
  1. Get Microsoft to sign their bootloader (cost: ~$99 one-time via Verisign)
  2. Use a shim—a small, Microsoft-signed bootloader that chains to the unsigned GRUB
  3. Disable Secure Boot (reduces security)
  4. Enroll custom keys (complex for typical users)

Most major distributions use the shim approach. The shim is signed by Microsoft and contains the distribution's own certificate, allowing it to verify and load the distribution's GRUB.

Unlike BIOS, which becomes completely inaccessible after the OS takes over, UEFI provides runtime services that remain available throughout system operation. This enables the OS to interact with firmware for specific tasks without requiring direct hardware access.

Boot Services vs Runtime Services:

• Boot Services — Available only during boot, before the OS calls ExitBootServices(). Include memory allocation, driver loading, protocol management. Terminated when OS takes control.

• Runtime Services — Survive ExitBootServices() and remain available to the running OS. Provide controlled firmware access for specific functions.

Variable Services in Practice:

The variable services are particularly important—they provide the mechanism for the OS to modify boot options, query firmware settings, and receive hardware information.

On Linux, UEFI variables are exposed via the efivarfs filesystem mounted at /sys/firmware/efi/efivars/. Each variable appears as a file whose name encodes the variable name and GUID.

The transition from BIOS to UEFI didn't happen overnight. For many years, systems included the Compatibility Support Module (CSM)—a UEFI component that emulates legacy BIOS, allowing old operating systems and bootloaders to function on UEFI hardware.

CSM Operation:

• Provides INT 13h, INT 10h, and other BIOS interrupts
• Enables MBR-based booting on GPT-aware hardware
• Runs 16-bit real-mode code within UEFI environment
• Typically configured in firmware setup as "Legacy Boot" or "CSM Mode"

The End of CSM:

Intel announced in 2017 that CSM support would be removed from UEFI by 2020. While this deadline slipped, the industry is firmly moving away from CSM:

• Windows 11 (2021) requires UEFI with Secure Boot—CSM cannot be enabled
• Intel 12th Gen and later platforms have limited or no CSM support
• ARM platforms never supported CSM at all
• Major motherboard vendors are removing CSM from consumer firmware

Dual-Boot Considerations:

Systems dual-booting multiple OSes must ensure consistency:

• All OSes booted via UEFI, or all via CSM (not mixed)
• Mixing leads to incompatible partition tables and boot confusion
• UEFI-installed Windows won't see CSM-installed Linux boot entries and vice versa

We've examined the firmware layer that transforms powered-off hardware into a system ready to boot an operating system. This foundation is invisible to most users but essential for every computation that follows.

What's Next:

The firmware hands control to a bootloader—an intermediate program that understands operating system requirements, allows boot option selection, and properly loads the kernel. In the next page, we'll examine GRUB, the most common Linux bootloader, and explore how bootloaders bridge the gap between firmware and operating system.