The kernel is just a program

It is easy, after Chapter 1, to think of the kernel as some abstract authority, a governing law of the machine. The Bridge at the close of Part I showed otherwise: the hardware supplies a contract (the privilege bit, the trap, the MMU, the timer, and MMIO with DMA), and on the kernel side of it is a program: instructions stored in memory and executed by the same CPU as everything else. The Linux kernel, as of 2025, is roughly 30 million lines of code, nearly all of it C. What makes it the kernel is not what it is made of but where it sits: in Ring 0, with hardware-enforced privileges no other program has.

When you press the power button, the CPU starts executing instructions from a fixed address in the motherboard's built-in firmware, historically called the BIOS and now usually UEFI. The firmware initialises hardware, finds the boot device, and loads a small program called a bootloader (GRUB on Linux, Windows Boot Manager, iBoot on Apple devices). The bootloader's only job is to find the kernel image on disk, load it into memory, and jump to its entry point. From that moment the kernel stays in memory, in charge of the machine, until it shuts down.

Monolithic vs microkernel: the great schism

Two philosophies of kernel design have been arguing since the late 1980s. A monolithic kernel puts everything in Ring 0: scheduling, memory management, filesystems, network code, and the device drivers that operate each piece of hardware. Its parts call each other directly, as functions in one program, so it is fast. The cost is safety: a bug in any part can corrupt the whole machine, and one flawed driver can hand it to an attacker. Linux and most kernels in production use are monolithic.

A microkernel puts only the absolute minimum in Ring 0, typically just message passing, basic memory protection, and minimal scheduling. Filesystems, drivers and network code run as separate programs in Ring 3 (the kernel maps just a driver's own device registers into it and passes on its device's interrupts as messages), which ask each other for work through messages the kernel carries. A bug in a driver then crashes only the driver. The cost is speed: every request between those parts crosses into the kernel and out again. Andrew Tanenbaum's MINIX is a microkernel; so is seL4, which is formally verified, meaning mathematically proven to have no kernel bugs of certain classes.

In 1992, Tanenbaum criticised the then-new Linux on a Usenet newsgroup, calling its monolithic design "obsolete" and "a giant step back into the 1970s." Linus Torvalds, its author, answered bluntly and at length. Tanenbaum was right that a microkernel contains a bug's damage; Torvalds, that a monolithic kernel was simpler and faster, and Linux ran on the machines people had. Neither design has displaced the other.

macOS sits in the middle. Its kernel, XNU, is a hybrid: a Mach microkernel core and a BSD UNIX layer sharing Ring 0, so its parts can pass messages like a microkernel's and call each other directly. iOS uses the same kernel. Android uses Linux. Windows NT began microkernel-influenced and has drifted toward monolithic design for speed.

Kernel modules: a third path

Linux softens its monolithic stance with loadable kernel modules (LKMs): drivers and filesystems compiled separately from the main kernel and loaded or unloaded at runtime with commands like insmod and rmmod. A machine can then load only the drivers its hardware needs, though a module still runs in Ring 0, where a buggy one can crash the kernel. Most graphics drivers, filesystem drivers, and hardware support on Linux ship as modules; lsmod on a running system lists hundreds of them.

Linux also limits the damage risky code can do: a few kinds of driver run as ordinary programs in Ring 3, where a crash takes down only that program, and the small eBPF programs of Section 06 run in the kernel only after a check proves them safe.

The art of taking turns

A modern laptop runs hundreds of processes; a server may run thousands. Your machine has at most a few dozen CPU cores, so most processes cannot be running at any given instant. The kernel creates the illusion that they all are by switching between them many times per second, too fast for you to perceive the gaps. The component that decides which process gets the CPU next is the scheduler, one of the most-studied parts of any kernel.

Cooperative vs preemptive: who interrupts whom

Many early personal-computer systems were cooperative, the model the Bridge described: each running program yielded the CPU back to the scheduler when it chose, so one that never yielded froze the entire machine. Mac OS through version 9 worked this way, as did 16-bit Windows.

Modern systems are preemptive: the kernel takes the CPU back from a running process at regular intervals, ready or not. The mechanism is the hardware timer interrupt: the Bridge's timer in each core, which Linux sets to fire 100–1000 times a second. Each interrupt forces the CPU into Ring 0, where the scheduler runs and either resumes the current process or switches to a different one.

What "scheduling" actually has to decide

Picking a process to run sounds trivial, but each classical algorithm makes a different trade-off:

Linux's CFS keeps every runnable process in a tree sorted by virtual runtime, a measure of how much CPU time the process has had, weighted by its priority: a high-priority process's virtual runtime grows more slowly, so it is picked more often. Smaller values sit to the left, and the leftmost process, furthest behind, runs next. After its turn it goes back in further right; one that stops to wait leaves the tree until it is ready. It is a red-black tree: each step down from the top rules out about half the processes still in play, so even thousands are reached in a dozen or so steps, and after each change the tree rearranges a few nodes so that no branch grows much longer than the rest. Every process thus tends toward its fair share. Since kernel 6.6 (2023), Linux's default is CFS's successor EEVDF (Earliest Eligible Virtual Deadline First), which keeps the same bookkeeping but gives every task a virtual deadline set by the slice it asks for, so a task that asks for short slices gets the CPU sooner without taking more than its share.

Real-time scheduling: when missing a deadline kills

General-purpose schedulers like CFS and EEVDF optimise for average performance and guarantee nothing about the worst case. That is fine for most software and catastrophic for an anti-lock braking system or a pacemaker. These systems run on real-time kernels: variants of Linux (PREEMPT_RT) or specialised OSes (VxWorks, QNX, FreeRTOS) that guarantee a task will run within a bounded time after it becomes ready, even under load. Liu and Layland analysed the two classic rules in 1973: rate-monotonic scheduling, in which the task that repeats most often gets the highest priority, and earliest-deadline-first.

The lie of unlimited memory

Chapter 1 introduced virtual memory, the private address space every process believes it owns, and the Bridge showed the silicon that enforces it: the MMU walking the page tables, the TLB remembering its answers. The kernel's side is the tables themselves, which it builds and keeps current, and what happens when the MMU finds no usable entry and calls on the kernel.

The translation problem

Every load and store uses a virtual address, which the MMU of Fig BR.4 translates to a physical address through the page table the kernel builds and keeps current.

Memory is divided into fixed-size blocks called pages, typically 4 KiB: virtual pages in the address space and physical pages in RAM. The page table maps one to the other. When a virtual page has no physical page in RAM (it has never been used, was moved to disk to free RAM, or belongs to a file mapped into memory but not yet read), its entry is marked invalid, and the MMU raises a hardware exception called a page fault. The kernel's page-fault handler decides what to do.

Why the page table cannot be flat

A flat page table would hold one entry for every possible virtual page. On 64-bit x86 a virtual address has 48 usable bits, enough for 2⁴⁸ bytes (256 TiB); split into 4 KiB (2¹²-byte) pages, that is 2³⁶ pages. At 8 bytes an entry, the table alone would need 512 GiB per process.

The solution, as the Bridge showed, is a multi-level page table: a tree of small tables, each one 4 KiB page of 512 entries. An address's last 12 bits are the page offset, the byte's place inside its page; the 36 bits above form four 9-bit indexes (2⁹ = 512), and each picks an entry on one level that points to the table below, the last to the physical page. Most of a process's 256 TiB is unused, and an empty entry near the top means no tables exist beneath it, so a real process needs a few megabytes of tables, not 512 GiB.

The TLB: a cache for translations

Walking all four levels on every access would turn each load into five memory reads, so the Bridge's Translation Lookaside Buffer (TLB) answers first, and a hit skips the walk. The cost the kernel has to manage is the miss: up to four extra memory reads, after which the MMU stores the result in the TLB.

A switch to another process drops the old translations unless each entry is tagged with its address space (PCID on x86), and even tagged, the processes compete for the same few entries.

Page faults: the productive kind

A page fault sounds like an error, but most are not: they are how the kernel implements many of its most useful features. Faults fall into three rough categories:

A minor page fault happens when no disk read is needed: the data is already in RAM but this process's page table has no entry for it yet (a page of a shared library another program has already loaded, say), or the page has never been used and the kernel simply hands over a fresh page of zeros. The kernel just adds the entry and returns. Cost: microseconds.

A major page fault happens when the data is not in RAM and must be fetched from disk: the page was moved to disk to free RAM, or the program is first reading part of a mapped file. The kernel issues a disk read, suspends the process, and resumes it when the data arrives. Cost: milliseconds, roughly a thousand times slower than a minor fault.

An invalid page fault happens when the access truly is illegal: writing to a read-only page, using an unmapped address such as 0 (NULL), executing data marked non-executable. The kernel sends the offending process a SIGSEGV signal (Section 05 covers signals), which by default ends the program with the famous "segmentation fault" message.

Two beautiful uses of page faults

Memory-mapped files. When you call mmap() on a file, the kernel doesn't read the file. It sets up page table entries marking the relevant virtual addresses as backed by that file, but invalid (not yet present). The first time you touch a page, you take a page fault, and the kernel reads just that one page from disk. Reading a 100 GB file as if it were one unbroken stretch of memory becomes trivial, because only the pages you touch are loaded. This is how some databases (LMDB) and search engines (Lucene) handle large data, and how every shared library loads on Linux.

Copy-on-write fork. When a UNIX process calls fork() to create a child process, the child receives a copy of the parent's entire address space, which done naively would mean duplicating gigabytes of memory. Instead the kernel marks all of the parent's pages read-only in the page tables, keeps its own note that they are really writable, and shares them with the child. Only when one of them tries to write does a page fault occur, and because of that note the kernel copies that one page instead of ending the process. Most pages are never written: a new program is launched by a fork followed at once by exec, which swaps in the new program's memory, so almost nothing is copied.

A tree of names on a flat array of blocks

A disk, at its lowest level, is a long row of numbered, fixed-size blocks: a spinning hard drive presents itself to the OS as billions of 512-byte sectors, and an SSD presents the same picture over entirely different hardware; the filesystem groups them into blocks, typically 4 KiB. From these blocks the filesystem builds the structure you actually use: named files in directories nested into a tree, each file recording its owner, permissions and timestamps, none of which the disk itself knows about.

The inode: where a file actually lives

In UNIX-derived filesystems, the central data structure is the inode, short for "index node." Every file has exactly one inode, and the inode contains everything about the file except its name and its data:

Notice what's not there: the filename. In UNIX, a filename is a property of the directory it lives in, not the file. A directory is itself a special kind of file whose contents are a list of (name, inode-number) pairs. To open /home/yki/notes.txt, the kernel looks up the inode for /, reads its directory contents to find the entry for home, follows that to the next directory's inode, and so on, until it reaches notes.txt's inode. Then it uses the inode's block list to read the actual data.

Because the name lives in the directory, a single file can have several names: multiple directory entries pointing to the same inode, called hard links. The file is only deleted when its link count drops to zero. For the same reason, renaming a huge file is instant: only the directory entry changes. The inode and its data don't move.

The everything-is-a-file principle

Chapter 1's creed, everything is a file, rests on the inode idea: UNIX gave devices and the kernel's own state names in the same tree. Most kernel-managed resources are reached this way:

• Your keyboard is one of the /dev/input/event* files.
• Random numbers come from /dev/urandom.
• The state of every running process lives under /proc/<pid>.
• Hardware sensors expose temperature and voltage as files in /sys.

None of these has data blocks on the disk: a read or write on one runs kernel code (a driver, for a device) that supplies or accepts the bytes. The same four system calls work on all of them: open, read, write, and close. This uniformity is one of the reasons UNIX-derived systems became so dominant: tools written for files work unchanged on devices and process state. The command that counts the lines of a text file, wc -l, counts them just as well in a sensor's readings under /sys or a process's records under /proc.

Journaling: the database technique that saved filesystems

A filesystem that simply writes data and metadata (the inodes, directories and free-block lists that keep track of it) to disk wherever convenient has a fatal weakness: power loss. If the machine crashes between writing data and updating its corresponding metadata (or vice versa), the filesystem becomes inconsistent: files exist whose blocks are still listed as free, or directory entries point at non-existent inodes. The classic UNIX response was fsck, a program that scans the entire disk after a crash to find and fix inconsistencies. On a multi-terabyte disk this could take hours.

The modern solution, borrowed from database theory, is the journal, a small, dedicated region of the disk where every change to the filesystem's own bookkeeping (inodes, the free list, directories) is written first, then applied to the main filesystem. Each change in the journal ends with a commit record, written last; after a crash, the kernel replays the changes that have one and discards those that do not. By default ext4 writes file contents to their place before the commit, so a committed change never points at missing data. Each change lands whole or not at all, and recovery takes seconds instead of hours. ext4 (Linux), NTFS (Windows), and HFS+ (older macOS) all journal. The technique is called write-ahead logging; we'll meet it again in Chapter 13.

The newest generation goes further: copy-on-write filesystems like ZFS, btrfs and (for its metadata) Apple's APFS never overwrite existing data. Their blocks hang in a tree from one root, each block holding the addresses of the blocks below it, so a change goes to new blocks, with a new parent for each (the parent holds the address that changed), up to a new root; one final pointer switch to that root makes it current, so a crash leaves either the old version or the new one whole. Keeping the old blocks makes snapshots, saved views of the whole filesystem at one moment, nearly free.

How processes talk

Processes are isolated by design: virtual memory and privilege separation exist so that one process cannot read or modify another's memory. But isolation taken to its extreme produces a useless system: programs that share nothing cannot pass each other data, or even say when a job is done. The kernel therefore exposes a controlled set of mechanisms for processes to communicate, collectively called inter-process communication, or IPC.

The kernel offers eight mechanisms:

The pipe: UNIX's most beautiful idea

The pipe reached UNIX in 1973: Doug McIlroy had been urging the idea for years, and Ken Thompson finally built it in an evening. A pipe is a kernel-allocated ring buffer, a fixed block of memory filled and emptied in a circle, with two file descriptors attached: one process writes to one end, another reads from the other. When the buffer is full the kernel makes the writer wait, and when it is empty the reader; the two programs share nothing but the stream of bytes.

In the shell, a pipe is written as a single character:

# Count how many unique lines start with "ERROR" in a log:
cat server.log | grep "^ERROR" | sort | uniq | wc -l

# Five separate processes, each doing one small thing.
# The shell creates pipes between them. Output of one
# becomes input of the next, streamed byte-by-byte.

Each program knows nothing about the others: it reads its standard input and writes its standard output; these are two file descriptors every program starts with, normally the keyboard and the screen, and the shell points them at the ends of pipes. All five run at once, each streaming into the next as fast as both can go. That is one reason UNIX produced a culture of small composable tools rather than monolithic applications.

Signals: a doorbell to a process

Pipes carry data. Signals carry no data, only the bare fact that something happened. A signal is a small, numbered notification delivered asynchronously to a process: number 2 (SIGINT) is what the kernel sends when you press Ctrl+C; number 9 (SIGKILL) is "stop now"; number 15 (SIGTERM) is the polite "please stop." A process can handle most signals (it registers a function; on arrival the kernel hijacks the process, runs the handler, then resumes), ignore them, or take the default action. Two signals, SIGKILL and SIGSTOP, can be neither handled nor ignored: the first always kills, the second always suspends.

Shared memory and semaphores: the no-copy IPC

Pipes are convenient, but every byte through one is copied twice, from the writer's memory into the kernel's buffer and then out into the reader's memory. For two processes on one machine that exchange large amounts of data, shared memory is the fastest mechanism, because it skips both copies: the two call into the kernel to map the same physical pages into both their virtual address spaces. After that, the region is ordinary memory, and no access involves the kernel.

The price of sharing is coordination: if two processes each read a shared count of 5, add 1 and write back 6, one addition is lost. Semaphores prevent this. A semaphore is a counter changed atomically, in one step that nothing can interrupt. A process that wants in decrements the counter, or sleeps if it is 0; one that leaves increments it, waking a sleeper. Initialised to 1, a semaphore admits one process at a time, a mutex; initialised to N, it is a pool of N. The idea is Edsger Dijkstra's, set out in his 1965 note "Cooperating Sequential Processes".

Sockets: when the other process is on another machine

A socket is a generalisation of the pipe: a connection either to another process on the same machine (a "UNIX domain socket") or to a process on a different machine entirely (a "network socket," using TCP or UDP). The same system calls apply: read, write, and close. The network drivers, the networking code in the kernel and the wire itself are all hidden beneath those few calls.

That is why a web browser, a database client, and a remote login (SSH) all use roughly the same code shape: open a socket, write a request, read a reply, close. Part III opens up what happens between write and read: ARPANET, packet switching, TCP, DNS, TLS, HTTP.

When the kernel breaks

Everything we've built in this chapter (the privilege boundary, the address-space isolation, the file permission checks, the IPC mediation) rests on one assumption: the kernel is correct. A bug in the kernel is therefore not an ordinary bug. A user-space program with a buffer overflow can be exploited to take over that program. A kernel with the same kind of bug can be exploited to take over everything: the kernel itself, every other process, every file, every keystroke.

Privilege escalation, more carefully

A privilege escalation attack is one where a process gains more privilege than it was supposed to have. The two important versions:

Vertical escalation: moving up the privilege ladder. A normal user process exploits a bug to become root (the administrator account), or root, on a system that walls even root off from the kernel (Secure Boot's lockdown mode, say), exploits a bug to enter Ring 0 (kernel mode).

Horizontal escalation: moving sideways at the same privilege level into another process's data. Reading another user's files, hijacking another user's session.

Kernel privilege-escalation bugs of the last decade include Dirty COW (the copy-on-write race condition mentioned earlier, 2016), DirtyPipe (a flaw in pipe-buffer initialisation that allowed writes to read-only files, 2022), and dozens of bugs in device drivers. Driver code is vast, often less audited than the core kernel, and runs in Ring 0. Most modern kernel exploits chain together multiple bugs: an information leak to find where the kernel sits in memory, defeating KASLR (the kernel's version of ASLR), then a memory-corruption bug to overwrite whatever grants privilege.

Containers: not virtual machines

Containers, the units Docker and Kubernetes run, are often described as "lightweight VMs," which is misleading. A virtual machine imitates an entire computer, kernel and all, on a hypervisor, a thin layer of software that lets one machine run several. A container is a normal Linux process that runs on the one shared kernel: a process the kernel has lied to, using two Linux features:

Namespaces partition kernel resources so that different processes see different views. There are namespaces for process IDs (a containerised process believes it is PID 1, even though to the host it might be PID 8472), for the network (the container has its own virtual network interface), for mounts (its own tree of files from / down, unpacked from a container image, not the host's), for user IDs, for hostnames, and more. Inside its namespaces, the container looks like a complete isolated system.

Cgroups (control groups) limit how much of each resource a process group can use: CPU time, memory, disk I/O, the number of processes. Together with namespaces, this gives Docker its model: cheap, fast isolation that doesn't require a hypervisor.

Each VM has its own guest kernel, so a kernel bug exposes only that VM unless the hypervisor has a flaw too; containers share one, so a kernel privilege-escalation bug can let a malicious container take over the host and every container beside it. Cloud providers that run strangers' code side by side therefore use VMs, or containers each wrapped in a minimal VM (AWS's Firecracker); machines that run one owner's code use plain containers, which are far cheaper.

eBPF: safe code inside the kernel

A more recent Linux feature is eBPF, "extended Berkeley Packet Filter." It allows user programs to upload small pieces of code into the running kernel, where they are attached to specific events (network packets, system calls, function entries) and run inside Ring 0.

The obvious worry is that this lets user code into the kernel, historically the worst possible security outcome. eBPF answers with a verifier: a checker in the kernel that reads every uploaded program and refuses to load it unless it can prove the program will always terminate, never read out-of-bounds memory, and never crash. Turing showed in Chapter 1 that no checker can decide whether every program ends, so the verifier settles for less: it accepts only programs simple enough to prove, such as loops with a known bound, and refuses everything else, even some programs that would have ended. Programs that pass are then translated into the CPU's own machine code and run essentially as fast as compiled kernel code. (Belt and braces: modern kernels also restrict who may load programs at all.)

eBPF now underlies much of Linux's tracing (bpftrace), networking (Cilium) and security monitoring (Falco). The same pattern recurs elsewhere: untrusted code runs inside a privileged place under constraints the machine enforces. eBPF proves the code harmless before it runs; the browser of Chapter 12 fences a web page's JavaScript in while it runs.