2.3 BIOS vs. UEFI & System Boot Process (101.2)

2.3 BIOS vs. UEFI & System Boot Process

Quick Summary: Booting a Linux system involves transitioning from hardware firmware to the operating system init process (PID 1). The two major firmware architectures are Legacy BIOS (utilizing Master Boot Record partition tables, 16-bit real mode, and a 2 TiB disk limit) and UEFI (utilizing GUID Partition Tables, 64-bit mode, an EFI System Partition, and NVRAM boot variables managed by efibootmgr). Understanding this sequence and its partition constraints is fundamental for LPIC-1 certification.

1. The Linux Boot Process Chronology

The boot process transforms dormant hardware into a functioning multi-user operating system through six distinct sequential phases.

[1. Power-On & POST] 
         │
         ▼
[2. Firmware Execution] ──────► Legacy BIOS  OR  Modern UEFI
         │
         ▼
[3. Bootloader Phase] ────────► BIOS: MBR (446 bytes) -> Stage 1.5 -> Stage 2 (GRUB 2)
         │                      UEFI: ESP (/boot/efi/EFI/<distro>/grubx64.efi)
         ▼
[4. Kernel Initialization] ───► vmlinuz decompressed into RAM, device probing
         │
         ▼
[5. Initramfs Root Pivot] ────► /init loads storage/RAID/LUKS drivers, mounts real root (/),
         │                      executes pivot_root / switch_root
         ▼
[6. Init System (PID 1)] ─────► systemd (or SysVinit) activates targets/services

Chronological Stages Detailed

1. Power-on & POST (Power-On Self-Test): System firmware stored in ROM/flash tests essential hardware (RAM, CPU registers, system timers, video adapter).
2. Firmware Initialization: Firmware enumerates attached boot devices according to configured boot priority.
3. Bootloader Execution:
   • BIOS: Reads the 512-byte Master Boot Record (MBR) on sector 0 of the boot disk, executes the 446-byte Stage 1 code, loads the core image (Stage 1.5), and loads the GRUB 2 configuration.
   • UEFI: Reads NVRAM boot entries, locates the EFI System Partition (ESP), and launches the .efi bootloader binary directly in 64-bit mode.
4. Kernel Loading & Decompression: The bootloader loads the compressed kernel (vmlinuz) and the initial RAM disk image (initramfs) into RAM. The kernel decompresses itself, initializes virtual memory and page tables, probes core CPU/ACPI structures, and starts kernel threads (PID 0 swapper and PID 2 kthreadd).
5. Initramfs Execution & Root Pivot: The kernel runs /init from the temporary in-memory root filesystem. It loads essential storage controllers (SATA, NVMe, LVM, Software RAID, LUKS encryption), mounts the real root filesystem (/) read-only, and calls switch_root to transition to the permanent filesystem.
6. PID 1 (Init System): The kernel executes /sbin/init (symlinked to systemd), which parses unit dependencies and starts system targets in parallel.

2. Architectural Comparison: Legacy BIOS vs. Modern UEFI

The MBR Structure (Sector 0: 512 Bytes)

The standard MBR sector consists of three distinct segments:

1. Bootstrap Code (446 Bytes): The machine code executed by BIOS (GRUB Stage 1).
2. Partition Table (64 Bytes): Four 16-byte partition entry records defining partition start, end, type flag, and bootable status.
3. Boot Signature (2 Bytes): Hexadecimal 0x55AA (validates MBR integrity).

3. The EFI System Partition (ESP)

In a UEFI environment, firmware does not execute raw machine code from sector 0. Instead, it natively understands the FAT32 (VFAT) filesystem and reads executable binaries compiled for the UEFI specification (.efi files).

Standard ESP Characteristics

• Partition Type GUID: c12a7328-f81f-11d2-ba4b-00a0c93ec93b (MBR Type 0xEF or GPT code EF00 in gdisk).
• Filesystem: FAT32 (FAT16/FAT12 supported by spec, FAT32 required for standard disks).
• Standard Mount Points: /boot/efi (Debian, Ubuntu, RHEL, CentOS) or /efi (Arch, systemd-boot).
• Directory Structure:

  /boot/efi/
  └── EFI/
      ├── BOOT/
      │   └── BOOTX64.EFI       # Fallback bootloader executable
      ├── ubuntu/
      │   ├── shimx64.efi       # First-stage Secure Boot loader
      │   ├── grubx64.efi       # GRUB 2 bootloader binary
      │   └── grub.cfg          # GRUB configuration file
      └── redhat/
          ├── shimx64.efi
          └── grubx64.efi
  

4. Managing UEFI Boot Entries: efibootmgr

efibootmgr is the Linux user-space tool used to inspect and manipulate UEFI NVRAM boot entries. It requires the efivarfs pseudo-filesystem to be mounted at /sys/firmware/efi/efivars.

# Inspect current UEFI boot entries and boot order
$ sudo efibootmgr -v
BootCurrent: 0001
Timeout: 2 seconds
BootOrder: 0001,0000,0002,0003
Boot0000* Windows Boot Manager  HD(1,GPT,a1b2c3d4-...,0x800,0x100000)/File(\EFI\Microsoft\Boot\bootmgfw.efi)WINDOWS...
Boot0001* ubuntu  HD(1,GPT,e5f6a7b8-...,0x800,0x100000)/File(\EFI\ubuntu\shimx64.efi)
Boot0002* Fedora  HD(1,GPT,e5f6a7b8-...,0x800,0x100000)/File(\EFI\fedora\shimx64.efi)
Boot0003* UEFI: IP4 Realtek PCIe GBE Family Controller  PciRoot(0x0)/Pci(0x1f,0x6)/MAC(001122334455,0)/IPv4(0.0.0.0...) ...

• BootCurrent: The hexadecimal boot entry ID used to boot the currently running system.
• BootOrder: The comma-separated priority sequence in which firmware attempts to boot devices.
• * indicator: Indicates an active boot entry (entries without * are disabled/inactive).

Crucial efibootmgr Command-Line Operations

5. Secure Boot Principles

UEFI Secure Boot is a verification mechanism designed to ensure that firmware will only execute bootloaders and operating system kernels that are cryptographically signed with trusted digital certificates.

Key Cryptographic Hierarchy

1. Platform Key (PK): Root of trust installed by the motherboard manufacturer; controls access to the KEK database.
2. Key Exchange Key (KEK): Keys authorizing updates to the signature database (db). Usually contains Microsoft and OEM keys.
3. Signature Database (db): Whitelist of cryptographic hashes and certificates for authorized bootloaders, drivers, and kernels.
4. Forbidden Signatures Database (dbx): Revocation blacklist of compromised keys and binary hashes.

The Linux Shim Mechanism

Because individual Linux distributions cannot easily have every daily kernel update signed directly by Microsoft, Linux uses a two-tier bootloader structure:

• shimx64.efi: A small, static first-stage loader signed by the Microsoft 3rd Party UEFI Certificate Authority. It initializes Secure Boot and contains the distribution vendor's certificate.
• grubx64.efi: The full GRUB 2 bootloader signed by the Linux distribution vendor.
• Machine Owner Key (MOK): Allows local administrators to generate and enroll custom signing keys for third-party out-of-tree kernel modules (e.g., proprietary NVIDIA drivers or VirtualBox hypervisors) using the mokutil utility.