What an OS Kernel Does

Strip away everything else, and a kernel is the one program the CPU trusts completely. Every other program — your shell, your browser, the code you'll write in this course's user mode — runs with the hardware's permission system pointed at it. The kernel is what that permission system points away from.

This isn't a convention. It's silicon.

Rings: privilege in hardware

Every x86 CPU tracks a 2-bit current privilege level (CPL) at all times. Four values, so four "rings":

• Ring 0 — kernel mode. Every instruction works. Every byte of memory is reachable.
• Ring 3 — user mode. The CPU refuses dangerous instructions and walls off memory the kernel didn't explicitly map for you.
• Rings 1 and 2 — designed for device drivers in the 1980s, unused by every mainstream OS. Paging only distinguishes "supervisor" (ring 0–2) from "user" (ring 3), so the middle rings never earned their keep.

What makes ring 0 special? Privileged instructions. Try any of these from ring 3 and the CPU raises a general-protection fault (#GP) instead of executing:

• hlt — stop the CPU until the next interrupt
• mov cr3, … — swap the page tables (i.e., swap the entire memory map)
• in / out — talk to device ports directly
• lgdt / lidt — replace the descriptor tables the CPU consults for, well, everything
• cli / sti — turn interrupts off and on

If a user program could run even one of these, isolation is over: it could remap memory (cr3), silence the scheduler (cli + hlt), or reprogram the disk controller (out) to read any file on disk.

How the CPU moves between rings

Here's the part people get wrong: user code can never jump to ring 0. There is no "please promote me" instruction. Every 3→0 transition happens because the CPU itself transfers control to a kernel-defined entry point:

• A system call — the program asks for service (syscall on x86-64). The CPU switches to ring 0 and jumps to the one handler address the kernel registered at boot. The program chooses when, the kernel chose where.
• An interrupt — a device (timer, keyboard, disk) raises a signal. Whatever was running is suspended mid-instruction-stream, and the CPU vectors into the kernel's handler at ring 0.
• An exception — the running code did something impossible: divided by zero, touched an unmapped page (page fault), executed a privileged instruction. Same mechanism as an interrupt, but triggered by the code itself.

And exactly one instruction goes back: iret (or sysret), which the kernel executes when it's done, dropping the CPU back to ring 3 at the point the user program left off.

That's the entire architecture of trust:

ring 3 ──syscall / interrupt / exception──▶ ring 0
ring 3 ◀─────────── iret / sysret ─────────  ring 0

Every context the CPU is ever in is one of these two states, and every arrow between them passes through code the kernel installed. Your exercise for this lesson is to build exactly this: a tracker that reads a stream of SYSCALL, INTR and IRET events, answers each PROBE with the ring the CPU is in right then, and quietly ignores any line it does not recognise. INTR is the interrupt and exception arrow above — both land in ring 0, and one arriving while already in ring 0 changes nothing — the same bookkeeping a kernel implicitly does every microsecond.

What the kernel does with that monopoly

Owning ring 0 makes the kernel responsible for everything that requires it:

1. Memory — decide which physical frames each process can touch, and lie to every process that it has a clean, private address space (next lessons).
2. CPU time — decide who runs next and take the CPU away from whoever has it (the timer interrupt is the enforcement mechanism — chapter 2).
3. Devices — own every in/out and memory-mapped register, exposing disks and keyboards as tidy abstractions like files and events.
4. Isolation — guarantee that a crashing or malicious process damages only itself.

One design split to keep in your head for the whole course: mechanism vs. policy. The context switch (mechanism) doesn't care which process runs next; the scheduler (policy) decides. Page tables (mechanism) don't care what gets mapped; the VM system (policy) decides. Good kernels keep the two separable — and this course builds them separately.

By the end you'll have written the boot handshake, the descriptor tables, the allocators, the scheduler, and the syscall layer — each one small, each one testable, and each one a piece of the only program the CPU trusts.