Section 6: CPU Privilege Levels

The Big Picture: The Problem This Solves

Imagine an office where every visitor had a key to every room, including the server room and the manager's files. One careless or dishonest person could cause chaos.

A computer has the same risk. If every piece of code (Windows itself, a driver, and a random game you downloaded) had unlimited access to hardware and memory, one buggy or malicious program could crash the whole system, read another program's private data, or reprogram a device directly. Privilege levels are the CPU's built-in, hardware-enforced answer.

x86/x64 CPUs have four possible privilege levels called rings, numbered 0 (most trusted) to 3 (least trusted). In practice, Windows (like almost all modern OSes) uses only two of them:

┌───────────────────────────────────────────┐
│  Ring 0 — KERNEL MODE                      │
│  Windows kernel, drivers                   │
│  Full hardware access, all memory          │
├───────────────────────────────────────────┤
│  Ring 1 / Ring 2 — unused by Windows       │
├───────────────────────────────────────────┤
│  Ring 3 — USER MODE                        │
│  Applications (Chrome, Word, games)        │
│  Restricted — must ask the kernel for help │
└───────────────────────────────────────────┘

(The kernel is the core of the operating system. It is the part that controls the hardware.)

6.1 Ring 0 (Kernel Mode)

What runs here: The Windows kernel (ntoskrnl.exe) and device drivers.

What it can do:

• Run any CPU instruction, including privileged instructions that control the CPU itself (changing privilege levels, managing the memory management unit, halting the processor)
• Access any memory address, belonging to any process
• Talk directly to hardware

Why so little runs here: Kernel code is fully trusted and has no limits. A bug here does not just crash one program. It can crash (or compromise) the whole system. This is why one buggy driver can cause a Windows Blue Screen of Death (BSOD), while a buggy app usually just closes itself.

6.2 Ring 3 (User Mode)

What runs here: Ordinary apps: your browser, games, Office, and almost all software.

What it cannot do:

• Run privileged CPU instructions
• Access hardware directly
• Read or write another process's memory
• Change system-critical data structures directly

How it still gets things done: When user-mode code needs a privileged action (reading a file, sending a network packet, getting memory), it must ask the kernel to do it. It does this through a controlled doorway called a system call (see 6.4).

6.3 Why Privilege Levels Exist

Three reasons, all enforced by the CPU hardware itself (not just by good manners in software):

6.4 Privilege Transitions (System Calls)

The problem: User mode is powerless on purpose. But apps constantly need privileged things done: opening a file, getting memory, drawing to the screen.

The solution: A system call. It is a tightly controlled doorway between Ring 3 and Ring 0. Think of a bank counter: you cannot walk into the vault, but you can ask the teller, who checks your request and fetches what you need.

User-mode application (Ring 3)
        │
        │  1. Application calls a Windows API function, e.g. CreateFile()
        ▼
Win32 API / ntdll.dll wrapper
        │
        │  2. Wrapper executes a special instruction (e.g. SYSCALL)
        │     This is the ONLY way to legally cross the boundary
        ▼
   ── PRIVILEGE TRANSITION: Ring 3 → Ring 0 ──
        │
        ▼
Windows kernel (Ring 0)
        │
        │  3. Kernel validates the request, performs the privileged
        │     operation (e.g. actually opens the file on disk)
        ▼
   ── PRIVILEGE TRANSITION: Ring 0 → Ring 3 ──
        │
        ▼
Application resumes in user mode with the result

Key points about a system call:

• The app cannot choose any code to run in kernel mode. It can only use a fixed, predefined set of kernel entry points. Each one checks its inputs before doing anything.
• The switch has a real cost (saving and restoring CPU state, changing privilege level). This is one reason apps that make too many system calls (for example many tiny file reads instead of one big one) run measurably slower.
• This is the only legitimate bridge between the untrusted world of apps and the trusted world of the kernel. Every "privileged" thing an app ever does goes through it.

Summary