# Linux Kernel Startup

Jesús Espino's "useful map" of the Linux kernel boot path on x86_64, threading a space-colony metaphor — advance team lands on a barren planet, builds infrastructure in a specific order, eventually transforms itself into the standby maintenance crew while a civilian government takes over. The six phases ([[linux-boot-phases]]) are the structural takeaway. References Linux v7.0 source throughout.

## The handoff

GRUB hands control to the kernel. The CPU is running but in one of several modes (UEFI lands us in Long Mode; legacy BIOS in Protected Mode). Memory is awkward: the kernel was loaded low in RAM (around `0x1000000`) but compiled to run at a high virtual address (`0xffffffff81000000`). All we have: an **E820 memory map** from firmware, ACPI tables, boot parameters. No console, no allocator, no interrupts, no log.

## Phase 1: Assembly trampoline

The `bzImage` is compressed. A decompressor in `arch/x86/boot/compressed/` unpacks the real image at a random base address — that randomization is **KASLR** (Kernel Address Space Layout Randomization). Then everything converges at `startup_64`: a working stack pointer gets installed, minimal **GDT** and **IDT** tables go in place.

A few specialized detours follow. SME/SEV/TME/TDX memory-encryption gets turned on right now — you can't go back and encrypt data already written in the clear. `verify_cpu` checks for Long Mode and SSE2 — this is why you can't run a 64-bit kernel on a 32-bit CPU; it fails the very first checklist item.

Then the **page-table fixup**: KASLR broke the linker's assumptions about where the kernel was loaded. `__startup_64()` computes the offset between "where the code thinks it is" and "where we actually landed" and patches every page-table entry. Virtual addresses translate to the right physical bytes again. Jump into the first C function, `x86_64_start_kernel`.

## Phase 2: Early C

We *are* the C runtime now — no library, no allocator. `clear_bss()` zeroes uninitialized globals (in a normal program, the runtime would). KASAN gets a placeholder: every byte of its shadow region points at a single zero page, so instrumented code reads zeros instead of crashing until real shadow exists.

`idt_setup_early_handler()` installs minimal handlers for Page Faults and General Protection Faults. Without one, a fault triggers a fault triggers a fault — three failures in a row and the CPU **triple-faults** into a silent reboot. `copy_bootdata()` saves the command line, memory map, and initrd location into kernel-owned `boot_params` before they get overwritten.

The surprising final step of Phase 2: `load_ucode_bsp()` patches the **CPU's own microcode**. Some CPU bugs (Spectre, MDS) are fixed by microcode updates themselves.

## Phase 3: setup_arch

`early_cpu_init()` calls **CPUID** and dumps the answers into `boot_cpu_data` — the lookup the kernel uses later for "do we have AVX-512?" feature checks. `e820__memory_setup()` cleans up the firmware's memory map (firmware is famously unreliable about it). `e820__memblock_setup()` feeds it into **`memblock`**, a primitive early allocator that just tracks "this range is free, this range is reserved." That's all we'll have for a while.

`parse_early_param()` sets up early printk if the command line requested it — the first time the kernel can talk to the outside world. `efi_init()`, `dmi_setup()`, `init_hypervisor_platform()` figure out what kind of machine and hypervisor we're on. `init_mem_mapping()` builds the **kernel direct map** — a region of virtual addresses where every physical page gets a fixed virtual address; after this the kernel can reach any byte of RAM by computing an offset. `reserve_initrd()` and `arch_reserve_crashkernel()` rope off the regions that can't be reused. `kasan_init()` finally sets up KASAN's real shadow, replacing the zero-page placeholder.

## Phase 4: start_kernel

The longest function in the boot path. `set_task_stack_end_magic()` arms a stack-smash tripwire. Interrupts are turned off — almost everything that follows runs with them disabled until much later. The Linux version banner gets pushed into the printk ring buffer (no console yet, so it sits there waiting).

Two interesting calls early: `jump_label_init()` and `static_call_init()` patch the kernel's own code so `if (some_flag)` checks become NOP or JMP at boot, and many indirect calls become direct. This is the start of [[kernel-self-patching]]. `early_security_init()` brings up the **LSM** (Linux Security Module) framework's most fundamental hooks.

`mm_core_init()` is the big one — the moment the colony stops surviving on emergency rations. After it returns, `kmalloc()`, `vmalloc()`, and `alloc_pages()` all work. Three layered allocators come up: the **buddy allocator** (page-grained, power-of-two blocks), the **slab allocator** SLUB (sits on top, specializes in objects like `task_struct` and `inode` — same trick as Go's `mspan`), and **vmalloc** (virtual-contiguous when physical can't be). `memblock_free_all()` hands every unreserved page to the buddy.

`sched_init()` sets up runqueues. Quietly, it turns `init_task` — the original boot thread — into the **boot CPU's idle task**. Everything after this point in `start_kernel()` is the idle task pretending to be init code.

`workqueue_init_early()` sets up the workqueue subsystem but doesn't hire workers yet — scheduled work piles up like tickets at an unstaffed help desk. (Workqueues hold pending function calls; runqueues hold tasks the scheduler picks from. Different things.) `rcu_init()` brings up **RCU (Read-Copy-Update)** — readers proceed completely lock-free, writers build a new copy and swap a pointer.

The interrupt/time/RNG stack comes up in a carefully ordered passage: `early_irq_init`, `init_IRQ` (per-interrupt bookkeeping; hardware *could* deliver but they're still masked); `tick_init`, `timers_init`, `hrtimers_init`, `softirq_init` (heartbeat and the two timer flavors); `timekeeping_init` (reads the real-time clock — first sensible answer to "what time is it?"); `random_init` (mixes early entropy from RDRAND, bootloader seed, boot-event timing). `boot_init_stack_canary()` finally installs a real random canary, replacing the predictable placeholder. Then `local_irq_enable()` — the colony just turned on its alarm system.

`console_init()` brings up the real console drivers and **drains the entire printk ring buffer** that's been piling up since the very first `pr_notice`. That's why the boot log appears in a sudden burst rather than a steady trickle.

`arch_cpu_finalize_init()` finishes CPUID-driven feature discovery, picks the right Spectre/Meltdown/MDS mitigations, sets up the FPU, and calls **`alternative_instructions()`** — patches every `ALTERNATIVE` macro site so the kernel is runtime-rewritten to be optimal for this exact CPU. Same `vmlinux` boots optimally on dozens of CPU generations. See [[kernel-self-patching]].

The last big block creates **slab caches** for every other subsystem: `fork_init()` (with `cred_init`, `signals_init`, `pagecache_init`) for `task_struct` and process plumbing — HR opens. `vfs_caches_init()` for the filesystem layer. `proc_root_init()` for `/proc`. `cgroup_init()`, `security_init()` (full LSM), `net_ns_init()` (namespace plumbing that lets containers exist).

## Phase 5: rest_init

`rest_init()` spawns two kernel threads: PID 1 (`kernel_init`, the future userspace init) and PID 2 (`kthreadd`, the kernel thread daemon that handles every `kthread_create()` for the lifetime of the system). Ordering trick: `kernel_init` is spawned first to get PID 1, then blocks on a completion until `kthreadd` is ready.

Then **the magic moment**: `rest_init()` calls `schedule_preempt_disabled()`. The scheduler context-switches away. When control eventually returns to this CPU, `cpu_startup_entry(CPUHP_ONLINE)` runs `do_idle()` forever. The original thread of execution — running since `startup_64` in raw assembly through every subsystem init — has permanently become the boot CPU's **idle task (PID 0)**. It only runs again when nothing else wants the CPU.

The advance team just clocked off and became the standby maintenance crew.

## Phase 6: kernel_init and userspace

`workqueue_init()` finally hires the `kworker/...` threads. `smp_init()` sends IPIs to wake the parked cores; each goes through its own simplified boot. `sched_init_smp()` builds the **scheduling domains** the load balancer uses — real multitasking begins.

`do_initcalls()` runs thousands of initcalls grouped into ordered levels (`early`, `core`, `subsys`, `fs`, `device`, `late`). This is where the boot log fills up with `PCI: Using ACPI for IRQ routing`, `ata1: SATA max UDMA/133 ...`, `ext4 filesystem driver registered`. `prepare_namespace()` mounts whatever `root=` specified — on modern distros, the initramfs unpacked into a `tmpfs`, with `/init` loading drivers and pivoting to the real root.

`free_initmem()` reclaims the `__init` section: `Freeing unused kernel memory: 2048K`. The setup-crew toolboxes get packed away. `mark_readonly()` flips `rodata` to actually read-only at the page-table level. `pti_finalize()` finalizes **PTI (Page Table Isolation)** — the Meltdown mitigation. The locks finally go on the doors now that the doors are installed.

The kernel walks candidate init paths in order: `rdinit=`, `init=` (if explicit and missing — panic), `CONFIG_DEFAULT_INIT`, `/sbin/init`, `/etc/init`, `/bin/init`, `/bin/sh` as last resort. `kernel_execve()` replaces the kernel thread with the userspace program. Same PID, same task, now running unprivileged code. The system is fully booted.

## What the article gets right that's worth keeping

- **Boot is a planned construction project, not a script.** Each phase unblocks a specific capability for the next one. Disabled interrupts protect the careful ordering; the first thing that runs with interrupts enabled is the console.
- **The kernel self-modifies aggressively at boot.** `jump_label`, `static_call`, `alternative_instructions` together rewrite the running text segment so a generic `vmlinux` becomes optimal for this specific CPU. This is the same `vmlinux` Debian ships boots on every x86_64 chip Debian supports.
- **PID 0 is the boot thread reincarnated.** Most "boot" content focuses on what got initialized; the article foregrounds where the boot thread *went* — it permanently became the idle task. This makes the `init_task → idle` relabeling stop feeling like a quirk.
- **`memblock` → buddy → SLUB → vmalloc is a real handoff**, not a layering. `memblock_free_all()` is the discrete moment ownership transfers.

## Cross-references

- [[linux-boot-phases]] — the six-phase model as a transferable concept
- [[kernel-self-patching]] — jump_label, static_call, alternative_instructions as one pattern
- [[linux-preemption-models]] — what happens to scheduling after boot completes
- [[linux-7-postgres-regression]] — why the post-boot preemption model matters for spinlock-heavy workloads
- [[spinlock]] — the synchronization primitive the disabled-interrupts era leans on
- [[linux-kernel-pgit]] — querying the kernel git history that produced this code
- [[internals-for-interns]] — Espino's blog, this article is the first in the kernel series
- [[operating-systems-three-easy-pieces]] — the subsystems this boot path is assembling in order (address spaces, the scheduler, allocators, the filesystem layer) get a chapter each in OSTEP; free online, and the right prerequisite if the phase-4 name-dropping went by too fast