Section 05: Boot Process — Overview
Section Purpose and Scope
The boot process is the moment a machine transitions from inert silicon to a running, responsive operating system. It is one of the most hardware-intimate sequences in systems software: each step is constrained by the previous step's environment, available memory is minimal, hardware is only partially initialized, and errors are catastrophic.
This section traces the entire sequence from power-on to the first user-space process, covering both the legacy BIOS path and the modern UEFI path, with particular attention to how security guarantees are established (Secure Boot, TPM, measured boot) and how the kernel itself transitions from compressed binary to running system. The init system and service startup are covered as the final stage of the boot chain.
Understanding this section is prerequisite for debugging boot failures, configuring secure boot, building custom embedded images, and understanding early-stage kernel exploits.
Prerequisites
- Section 00 (Foundations): privilege rings, interrupts, hardware abstraction
- Section 03 (Kernel Fundamentals): kernel initialization sequence (
start_kernel()) - Section 06 (CPU Architecture): CPU modes (real mode, protected mode, long mode) — helpful but not strictly required
Learning Objectives
After completing this section you will be able to:
- Describe the complete x86 boot sequence from power-on to user space, at each stage naming what code is running, in what CPU mode, with what memory map
- Explain the difference between BIOS and UEFI architecturally and why UEFI replaced BIOS
- Describe MBR and GPT partition table formats and their limitations
- Explain GRUB2's stages and how it loads a kernel
- Describe how the kernel decompresses itself and transitions from the bootloader environment
- Explain the role of initramfs and why it exists
- Compare SysVinit, Upstart, and systemd architecturally
- Explain Secure Boot, TPM attestation, measured boot, and verified boot end-to-end
- Parse and modify the kernel command line
Architecture Overview
COMPLETE BOOT SEQUENCE (x86-64, UEFI + GRUB2 + Linux)
Power On
│
▼
CPU Reset Vector: 0xFFFFFFF0 (16-bit real mode)
│ Executes first instruction from firmware ROM
▼
UEFI Firmware (SEC phase — Security)
│ CPU cache-as-RAM (CAR); minimal stack
│ Verifies firmware integrity (if Secure Boot)
▼
UEFI Firmware (PEI phase — Pre-EFI Initialization)
│ Initializes DRAM controller
│ Configures memory map
▼
UEFI Firmware (DXE phase — Driver Execution Environment)
│ Loads EFI drivers from firmware
│ Initializes PCIe, NVMe, USB, network
│ Builds EFI System Table
▼
UEFI Firmware (BDS phase — Boot Device Selection)
│ Reads NVRAM boot order
│ Locates EFI System Partition (ESP, FAT32)
│ Loads and executes EFI bootloader
▼
GRUB2 (grubx64.efi — still in UEFI mode, 64-bit)
│ Reads grub.cfg
│ Locates kernel image (vmlinuz) + initramfs
│ Optionally shows boot menu
│ Calls ExitBootServices() ← UEFI firmware hands off
▼
Kernel Entry Point (startup_64 / efi_stub)
│ CPU in 64-bit long mode (UEFI already set this up)
│ Decompresses vmlinuz → vmlinux in-place
│ Sets up early page tables
│ Disables UEFI runtime services (mostly)
▼
start_kernel() (arch-independent C)
│ Initializes: memory zones, per-CPU data, IRQs
│ Mounts initramfs as rootfs
│ Starts kernel threads (kswapd, kworker, etc.)
▼
initramfs (tmpfs in RAM)
│ Contains minimal userspace: udev, mount, modprobe
│ Loads drivers needed to mount real root filesystem
│ Pivot_root or switch_root to real /
▼
/sbin/init (PID 1 — systemd on most modern Linux)
│ Reads unit files (/etc/systemd/system/)
│ Dependency-based parallel service activation
│ Mounts filesystems, starts network, getty...
▼
Login prompt / Display Manager
BIOS vs. UEFI COMPARISON:
┌─────────────────────┬─────────────────────────────────┐
│ BIOS │ UEFI │
├─────────────────────┼─────────────────────────────────┤
│ 16-bit real mode │ 32/64-bit protected/long mode │
│ ~1MB address space │ Full 64-bit address space │
│ MBR (512 bytes) │ GPT + EFI System Partition │
│ Max 2.2TB disk │ Max 9.4 ZB disk (GPT) │
│ No network boot API │ PXE boot via EFI network stack │
│ No signing │ Secure Boot (X.509 signatures) │
│ INT 13h disk API │ EFI Block I/O Protocol │
│ POST takes 30s+ │ Fast Boot (skip hardware init) │
└─────────────────────┴─────────────────────────────────┘
Key Concepts
- POST (Power-On Self-Test): Firmware routine that verifies CPU, RAM, and essential hardware are functional before beginning the boot sequence.
- BIOS (Basic Input/Output System): Legacy PC firmware. Initializes hardware and loads the first 512-byte sector (MBR) of the boot device into address 0x7C00, then jumps to it. Operates in 16-bit real mode with only 1MB addressable.
- UEFI (Unified Extensible Firmware Interface): Modern firmware standard (Intel EFI, 2000; UEFI Forum, 2005). Operates in 32 or 64-bit mode; provides a rich pre-boot API including file system drivers, network stack, and cryptographic services.
- MBR (Master Boot Record): First 512 bytes of a disk. Contains a small bootloader and the partition table (max 4 primary partitions, max 2.2TB disk). Being superseded by GPT.
- GPT (GUID Partition Table): Modern partition table format, part of the UEFI standard. Supports up to 128 partitions, 9.4 ZB disks, stores CRC32 checksums, and maintains a backup table at the end of disk.
- EFI System Partition (ESP): A FAT32 partition containing EFI bootloaders (
/EFI/BOOT/BOOTX64.EFI, distro-specific entries). The UEFI firmware can directly read this partition without a bootloader. - GRUB2: GNU Grand Unified Bootloader, version 2. The dominant x86 Linux bootloader. Supports BIOS and UEFI, reads ext4/BTRFS/XFS/LUKS, provides a rescue shell, supports TFTP/HTTP network booting.
- vmlinuz: The compressed, bootable Linux kernel image. The
zsuffix indicates it's self-decompressing (gzip originally, now typically zstd or LZ4). - initramfs (initial RAM filesystem): A
cpioarchive embedded in or alongside the kernel image. Mounted as the initial root filesystem. Contains just enough userspace to load modules and mount the real root filesystem. - Secure Boot: A UEFI feature that verifies the digital signature of each bootloader and OS against a whitelist of trusted certificates stored in UEFI NVRAM. Prevents unauthorized code execution before the OS loads.
- TPM (Trusted Platform Module): A hardware security chip (or firmware equivalent — fTPM) that provides: cryptographic key storage, attestation (proving what software is running), sealing (encrypting data that can only be decrypted in a specific boot state), and random number generation.
- Measured Boot: Each boot component (firmware, bootloader, kernel, initramfs, kernel command line) hashes its successor and extends the hash into TPM PCR (Platform Configuration Register) banks. Creates a tamper-evident log of the boot chain.
- Verified Boot (ChromeOS) / UEFI Secure Boot: Different implementations of the same concept — cryptographically verify each boot stage before executing it.
- kernel command line: Parameters passed to the kernel by the bootloader (e.g.,
root=/dev/nvme0n1p2 quiet splash mitigations=off). Affects driver behavior, memory limits, debug level, and security features.
Major Historical Milestones
| Year | Milestone |
|---|---|
| 1981 | IBM PC BIOS — INT 13h, 640KB RAM limit, the legacy begins |
| 1983 | IBM XT: first hard disk boot via MBR |
| 1992 | LILO (Linux Loader) — first Linux-specific bootloader |
| 1995 | GRUB 0.1 (Erich Boleyn) — flexible bootloader with command line |
| 1999 | Intel EFI 1.0 for Itanium — BIOS replacement begins |
| 2003 | GPT introduced with UEFI 1.1; 2TB disk barrier broken |
| 2005 | UEFI Forum founded; x86 UEFI support begins |
| 2007 | TPM 1.2 becomes standard on enterprise hardware |
| 2011 | Windows 8 mandates UEFI Secure Boot for certification |
| 2012 | GRUB 2.0 released with full UEFI support |
| 2012 | Microsoft shim layer enables Linux Secure Boot |
| 2014 | ChromeOS Verified Boot widely deployed in Chromebooks |
| 2016 | TPM 2.0 becomes standard; Intel Boot Guard |
| 2019 | systemd-boot and unified kernel images gain traction |
| 2020 | GRUB2 BootHole vulnerability (CVE-2020-10713) — Secure Boot bypass |
| 2022 | Linux Kernel's own EFI stub loader matures; direct boot without GRUB |
| 2023 | UEFI Secure Boot key rotation crisis (BlackLotus UEFI bootkit) |
Modern Relevance and Production Use Cases
Cloud instance boot: Every AWS EC2 instance, GCP VM, and Azure VM goes through a boot sequence. Understanding UEFI, kernel command line, and initramfs is essential for: building custom AMIs, debugging startup failures, optimizing cold-start time for serverless.
Measured boot and attestation: Kubernetes node attestation, confidential computing (AMD SEV, Intel TDX), and TPM-based disk encryption (BitLocker, LUKS with TPM unsealing) all depend on the measured boot chain.
Security hardening: Secure Boot prevents most bootkit attacks. But misconfigured Secure Boot (wrong shim, outdated certificate, missing revocation) leaves gaps. Every cloud security posture assessment includes checking boot integrity.
Embedded Linux: Yocto, Buildroot, and OpenWRT projects require understanding the entire boot sequence to build minimal images. Custom bootloaders (U-Boot, Barebox) replace GRUB on ARM boards.
Debugging boot failures: systemd-analyze blame, systemd-analyze critical-chain, journalctl -b, early console output (console=ttyS0,115200), GRUB rescue shell — all require knowing where in the boot sequence the failure occurred.
File Map
05-boot-process/
├── 00-overview.md ← This file
├── 01-power-on-and-firmware.md ← CPU reset, POST, firmware phases
├── 02-bios-boot.md ← INT 13h, MBR structure, 640K limit
├── 03-uefi-boot.md ← UEFI phases, EFI system table, driver model
├── 04-mbr-and-gpt.md ← Partition table formats, CHS geometry legacy
├── 05-grub2.md ← Stage 1/2, grub.cfg, rescue mode, modules
├── 06-kernel-decompression.md ← vmlinuz self-extraction, real→protected→long mode
├── 07-initramfs.md ← cpio format, dracut, mkinitcpio, pivot_root
├── 08-init-systems.md ← SysVinit, Upstart, systemd unit files, dependency graph
├── 09-secure-boot.md ← X.509 chain, shim, MOK, revocation
├── 10-tpm-and-measured-boot.md ← PCR banks, attestation, LUKS+TPM unsealing
├── 11-kernel-command-line.md ← Reference of important parameters
├── 12-arm-and-embedded-boot.md ← U-Boot, Device Tree, ARM Trusted Firmware
Cross-References
- Section 03 (Kernel Fundamentals):
start_kernel()sequence that begins where this section ends - Section 05→Section 06: CPU mode transitions (real → protected → long) covered in CPU Architecture
- Section 19 (Virtualization): Virtual machine boot (OVMF UEFI for QEMU, BIOS emulation)
- Section 26 (Security): Secure Boot policy, TPM-based attestation in production
- Section 34 (Embedded Systems): U-Boot, Device Tree, custom embedded boot chains
Recommended Depth of Study
Essential: Files 01–08. Understanding the full boot sequence from firmware to init is fundamental for any systems engineer.
Deep dive recommended: Files 09–10 for security engineers, cloud infrastructure, and confidential computing. File 12 for embedded and ARM work.
Hands-on: Boot a Linux VM in QEMU with -bios (BIOS mode) and with OVMF (UEFI mode). Add earlyprintk=serial console=ttyS0 to observe the transition. Inspect PCR values via tpm2-tools.
Estimated study time: 10–15 hours including hands-on exercises.