Kernel, user space and system calls

Every program on Linux is a guest. It cannot touch the disk, the network card, or another program's memory. It has to ask. This page is about who it asks, how the asking works, and how the thing it asks came to be running in the first place.

The map

Read this first when short on time. Every branch is a section below.

The kernel: one program that owns the hardware

The kernel is a single program that is loaded first and stays in memory the whole time the machine is on. It owns the CPU, the memory and every device. Everything else runs on top of it and has to ask it for things.

"Linux" strictly means only this program. Ubuntu, Fedora, Alpine and Android are the same kernel with different user space around it: a C library, a shell, an init system, package tools. That is why a Docker image built on Debian runs on a Fedora host. The image brings its own user space; the kernel underneath is the host's.

Inside, the kernel is a set of subsystems that share one address space:

• The scheduler decides which task runs on which CPU, and for how long.
• Memory management hands out pages and keeps every process's view of memory separate.
• The VFS (virtual filesystem) turns open and read into calls on ext4, XFS, tmpfs or NFS.
• The network stack owns sockets, TCP, IP and routing.
• Device drivers talk to the actual hardware.

flowchart TD
  A["Applications: shell, nginx, Chrome, your code"] --> L["C library: glibc, musl, Bionic"]
  L --> S["System call interface"]
  S --> K
  subgraph K["Kernel"]
    direction LR
    K1["Scheduler"] ~~~ K2["Memory"] ~~~ K3["VFS"] ~~~ K4["Network"]
  end
  K --> D["Device drivers"]
  D --> H["Hardware: CPU, RAM, disk, NIC"]

Linux is a monolithic kernel: drivers and filesystems run inside the kernel itself, not as separate programs. But it loads code on demand. A driver can be a module, a .ko file that modprobe pulls in when the hardware shows up. lsmod lists what is loaded right now. Once loaded, a module is kernel code with full power; a bug in it can take the whole machine down.

Kernel

The one program with full control of the hardware. Loaded first, never exits.

Distribution

A kernel plus a chosen user space: libc, shell, init, packages.

Module

A piece of kernel code loaded at runtime, usually a driver or a filesystem.

Kernel space and user space: two modes on one CPU

The CPU has a privilege level, and the kernel runs at the highest one. User programs run at the lowest. That single hardware fact is what keeps a buggy program from wrecking the machine.

On x86 the levels are called rings. The kernel runs in ring 0 and can do anything: touch any memory, talk to any device, change the page tables. Applications run in ring 3. If a ring 3 program tries a privileged instruction, such as turning off interrupts or writing to a device register, the CPU refuses and jumps into the kernel, which usually kills the program. ARM has the same idea with different names (EL1 and EL0).

Memory is split the same way. Every process gets its own address space, and the kernel's memory is mapped into the top of each one but marked as not accessible from user mode. So a process cannot read another process's memory, and it cannot read the kernel's either. The page tables enforce this, and only the kernel can change the page tables. The memory article goes through how those tables work.

There are exactly three ways control passes from user mode to kernel mode:

1. A system call. The program asks for something on purpose. This is the next section.
2. An interrupt. A device or the timer needs attention. The program is paused, the kernel handles it, the program resumes without knowing.
3. An exception. The program did something the CPU could not complete: touched an unmapped page, divided by zero, ran a privileged instruction. The kernel decides whether to fix it (a page fault) or kill the process (a segmentation fault).

Each crossing is a mode switch: the CPU saves where the program was, jumps to a kernel entry point, and later restores the program. It is cheap but not free, which is why the number of system calls a program makes matters for performance.

Ring 0 / ring 3

The x86 names for privileged and unprivileged CPU mode. The kernel is ring 0.

Mode switch

The CPU moving from user mode to kernel mode or back. Happens on every system call, interrupt and exception.

Context switch

Different thing: the kernel switching the CPU from one process to another. Includes swapping the page tables.

System calls: the only door into the kernel

A system call is how a user program asks the kernel to do something it cannot do itself: open a file, send a packet, start a process, allocate memory. There are over 400 of them on x86-64, and every one has a number.

You almost never make one directly. You call a function in the C library, and the library makes the call for you. Here is what happens when a program writes five bytes to standard output:

sequenceDiagram
  autonumber
  participant P as Program
  participant L as libc
  participant K as Kernel
  participant F as Filesystem
  P->>L: write(1, "hello", 5)
  L->>L: number 1 in rax, args in rdi rsi rdx
  L->>K: syscall instruction (mode switch)
  K->>K: look up entry 1 in the syscall table
  K->>F: sys_write: find fd 1, copy bytes in
  F-->>K: 5 bytes accepted
  K-->>L: rax = 5, return to user mode
  L-->>P: 5

1. The program calls write in libc.
2. libc puts the system call number in a register (rax on x86-64) and the arguments in others (rdi, rsi, rdx, r10, r8, r9).
3. libc runs the syscall instruction. The CPU switches to ring 0 and jumps to the kernel's entry point. On ARM64 the instruction is svc and the number goes in x8.
4. The kernel saves the program's registers, reads the number, and looks up the handler in the syscall table. Entry 1 is sys_write.
5. The handler checks the arguments. Every pointer from user space is treated as untrusted: the kernel copies data across with copy_from_user, which fails cleanly instead of crashing if the address is bad.
6. The work happens: find file descriptor 1 in the process's table, hand the bytes to whatever is behind it (a terminal, a pipe, a file in the page cache).
7. The kernel puts the result in rax and returns to user mode. A success is a value of zero or more. A failure is a small negative number, the negated error code.
8. libc sees the negative value, stores the positive code in errno, and returns -1 to the program.

The C looks like this. Everything in the sequence above is hidden inside the one call to write.

#include <unistd.h>
#include <errno.h>
#include <stdio.h>

int main(void) {
    ssize_t n = write(1, "hello", 5);   // fd 1 is standard output
    if (n < 0) {
        perror("write");                // prints the message for errno
        return 1;
    }
    return 0;
}

strace shows the crossings and nothing else. Run it on the program above and the interesting line is the one in the middle:

$ strace ./hello
execve("./hello", ["./hello"], 0x7ffd...) = 0
brk(NULL)                               = 0x5555...
mmap(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f...
...
write(1, "hello", 5)                    = 5
exit_group(0)                           = ?

The lines before write are the dynamic loader setting up libc. Even the smallest program makes a few dozen system calls before reaching main.

The ones worth knowing by name

What a system call costs

A bare system call is a few hundred nanoseconds: two mode switches, the register save and restore, and the table lookup. After the Meltdown mitigations it is more, because the kernel's page tables are swapped in and out too. That is small next to a disk read, but a program doing millions of tiny reads pays for every one. This is why buffered I/O exists, and why high-performance servers batch work per call.

A few calls are so common that the kernel avoids the trap entirely. clock_gettime, gettimeofday, time and getcpu are served by the vDSO, a small page of kernel-provided code mapped into every process. libc calls it like an ordinary function, it reads a shared memory page the kernel keeps up to date, and no mode switch happens. strace does not show these at all.

System call

A request from user space to the kernel, identified by a number and made with a special CPU instruction.

Syscall table

The kernel's array mapping call numbers to handler functions.

errno

A per-thread variable in libc holding the error code of the last failed call. ENOENT, EACCES, EAGAIN are values of it.

vDSO

Virtual dynamic shared object. Kernel code mapped into each process so a few calls, mostly about time, need no mode switch.

The C library: the wrapper you actually call

The C library sits between every program and the kernel. It wraps each system call in a normal function, and it adds a lot that is not a system call at all.

On most distributions it is glibc. Alpine uses musl, which is smaller and simpler, and Android uses Bionic. Every other language runtime sits on one of these, or, like Go, reimplements the thin layer itself. A program compiled against glibc will not run on an Alpine image, which is the usual reason a container "works on my machine" and not in production.

The library does three jobs:

• Wrapping. open, read, write, fork and friends are one-line wrappers that set registers, run syscall, and turn a negative return into errno.
• Buffering. printf and fwrite collect bytes in a buffer and call write only when it fills up, or at a newline if stdout is a terminal, or at exit. That turns a thousand tiny writes into one system call.
• Everything else. malloc, strlen, qsort, getaddrinfo, locale handling. None of these are system calls on their own. malloc asks the kernel for big chunks with brk or mmap and carves them up in user space.

The buffering catches people. Print a line with printf and then crash, and the line never appears, because it was still in the buffer. Pipe a program's output into another command and the lines come out late and in blocks, because stdout is no longer a terminal so it is fully buffered. fflush(stdout), setvbuf, or writing to stderr (which is unbuffered) are the fixes. strace makes it visible: you see one write of 4096 bytes instead of a hundred small ones.

glibc

The GNU C library, the default on Debian, Ubuntu, Fedora and RHEL.

musl

A small, strict C library used by Alpine Linux and for static binaries.

Buffered I/O

Collecting output in memory and writing it in large chunks. stdio does it, raw write does not.

Interrupts: how the kernel takes the CPU back

A system call is the program handing control to the kernel. An interrupt is the kernel taking it. A device raises a signal on a wire, the CPU stops what it was doing mid-instruction, and jumps into a kernel handler.

flowchart TD
  A["Device raises an IRQ: packet arrived, disk finished, timer tick"] --> B["CPU pauses the running task, enters the kernel"]
  B --> C["Top half: acknowledge the device, grab the data, return in microseconds"]
  C --> D["Bottom half: softirq or workqueue does the slow part later"]
  D --> E["Wake the process that was waiting on this"]
  E --> F["Scheduler picks who runs next, returns to user mode"]

Handlers are kept short because while one runs, that CPU cannot take another interrupt. So the handler does the minimum, the top half, and queues the rest as a softirq or a work item, the bottom half. For a network card, the top half notes that packets are in the ring buffer and the bottom half walks them up through IP and TCP.

The most important interrupt is the timer. It fires every few milliseconds on each CPU, and the handler gives the scheduler a chance to decide the current task has run long enough. Without it, a program in an infinite loop would own the CPU forever. This is what makes the kernel preemptive: a task is paused whether it likes it or not. Modern kernels also switch the tick off on an idle CPU to save power.

IRQ

Interrupt request. A numbered line a device uses to get the CPU's attention.

Softirq

Deferred kernel work that runs soon after the interrupt handler, with interrupts enabled again.

Preemption

The kernel pausing a running task on its own decision, not the task's.

Boot: from firmware to the first process

Booting is a chain of programs, each one just capable enough to load the next. It ends when the kernel starts the first user space process.

flowchart TD
  A["Firmware (UEFI): test hardware, find a boot entry on the disk"] --> B["Bootloader (GRUB, systemd-boot): pick a kernel, load it and the initramfs into RAM"]
  B --> C["Kernel: decompress, set up page tables, start CPUs, probe devices, load drivers"]
  C --> D["initramfs: a tiny root filesystem in RAM. Its init loads the modules needed to reach the real disk"]
  D --> E["Mount the real root, switch to it"]
  E --> F["Run /sbin/init as PID 1: systemd"]
  F --> G["systemd starts services, mounts, the login screen"]

1. Firmware. UEFI (or the old BIOS) initialises the hardware, reads its boot entries from NVRAM, and runs the bootloader from the EFI system partition. Cloud VMs and the Raspberry Pi have their own firmware that does the same job.
2. Bootloader. GRUB or systemd-boot shows a menu, loads the compressed kernel image (vmlinuz) and the initramfs into memory, passes the kernel command line (root=, quiet, ro), and jumps to the kernel.
3. Kernel. It decompresses itself, sets up memory and page tables, brings up the other CPUs, and probes for devices. This is the wall of text on a console boot.
4. initramfs. A small root filesystem packed as a cpio archive. The kernel unpacks it into RAM and runs its /init. That script loads the driver modules needed to reach the real root disk, unlocks encrypted volumes, assembles RAID. Without it the kernel would need every possible disk driver built in.
5. Real root. The initramfs mounts the real root filesystem and moves into it with switch_root, freeing the RAM copy.
6. PID 1. The kernel execs /sbin/init, which is a symlink to systemd on most distributions. This is the first and only process the kernel ever starts by itself. Every other process is a descendant of it. If PID 1 exits, the kernel panics.

Two tasks exist alongside PID 1 from the start: kthreadd (PID 2), the parent of every kernel thread, and the idle task (PID 0). They are why ps shows names in square brackets like [kworker/0:1]. Those are kernel-space tasks with no user space program.

UEFI

The firmware standard that replaced BIOS. Finds and runs the bootloader.

initramfs

A small filesystem in RAM used during boot to load the drivers needed to reach the real root disk.

PID 1

The first user space process. The ancestor of all others. systemd on most systems.

systemd: PID 1 and everything it supervises

systemd is the init system on nearly every current distribution. As PID 1 it starts every service, keeps them running, and is the parent every orphaned process ends up under. It also runs the logging daemon, mounts filesystems, and manages timers, devices and login sessions.

Units

Everything systemd manages is a unit, described by a small text file. The type is the file's suffix.

A service file says what to run and how to treat it:

[Unit]
Description=My API server
After=network-online.target postgresql.service
Wants=network-online.target

[Service]
Type=simple
User=api
ExecStart=/opt/api/bin/server --port 8080
Restart=on-failure
RestartSec=2
MemoryMax=512M
Environment=RUST_LOG=info

[Install]
WantedBy=multi-user.target

Two kinds of relationship matter. After and Before are about order: start me after that. Wants and Requires are about pulling in: if I start, start that too (and with Requires, fail if it fails). They are independent. A unit that Wants another without After starts both at the same time. The [Install] section only says which target should pull this unit in when it is enabled.

Targets and the boot order

A target is a checkpoint. Boot is systemd working its way to default.target, which is a symlink to multi-user.target on a server or graphical.target on a desktop. The targets chain, and services hang off them.

flowchart TD
  S["sysinit.target: mounts, udev, journald, swap"] --> B["basic.target: sockets, timers, paths"]
  B --> M["multi-user.target: sshd, nginx, docker, cron"]
  M --> G["graphical.target: display manager, login screen"]
  D["default.target"] -. symlink .-> M

Services start in parallel wherever the ordering allows it, which is why systemd boots faster than the old shell-script init. systemd-analyze blame lists what took longest, and systemd-analyze critical-chain shows the path that set the boot time.

Supervision

systemd puts each service in its own cgroup, so it knows exactly which processes belong to it even if the service forks a hundred times. That is how systemctl stop reliably kills everything, and how MemoryMax= and CPUQuota= in a unit file turn into real limits. The containers article covers cgroups in full.

It restarts services that die (Restart=on-failure), and it can hold a socket open on a service's behalf and only start the service when the first client connects (socket activation). Logs go to journald, which captures stdout and stderr of every service into a binary, indexed journal.

systemctl status nginx          # running? PID, cgroup, recent log lines
systemctl start|stop|restart nginx
systemctl enable --now nginx    # start at boot and start now
systemctl list-units --type=service --state=failed
systemctl cat nginx             # the unit file plus drop-ins
systemctl edit nginx            # add an override in /etc/systemd/system/nginx.service.d/
systemctl daemon-reload         # after editing unit files by hand
journalctl -u nginx -f          # follow one service's log
journalctl -b -p err            # errors since this boot
systemd-analyze blame           # what slowed the boot

Unit files that ship with a package live in /usr/lib/systemd/system/. Your changes go in /etc/systemd/system/, either as a whole file that shadows the packaged one or as a drop-in directory that overrides a few lines. That is the same split as everything else under /usr and /etc, explained in the filesystems article.

Unit

One thing systemd manages: a service, socket, mount, timer, target.

Target

A unit that groups others. Used as boot milestones like multi-user.target.

journald

systemd's log collector. journalctl reads it.

Socket activation

systemd holds the listening socket and starts the service on the first connection.

Recap