User vs Kernel Mode
[!NOTE] This module explores the core principles of User vs Kernel Mode, deriving solutions from first principles and hardware constraints to build world-class, production-ready expertise.
1. The Trust Issue
The OS cannot trust the user. If a user program could access any memory address, it could:
- Overwrite the Kernel’s code.
- Read passwords from another process’s memory.
- Turn off the cooling fan and melt the CPU.
To prevent this, the CPU hardware enforces Protection Rings.
2. x86 Protection Rings
Intel/AMD CPUs support 4 privilege levels (Rings 0-3).
- Ring 0 (Kernel Mode): God mode. Can execute any instruction (
HLT,LGDT,IN/OUT) and access any memory address. - Ring 1 & 2: Designed for drivers, but rarely used by modern OSs (Linux/Windows use only 0 and 3).
- Ring 3 (User Mode): Peasant mode. Restricted. Cannot touch hardware directly.
Diagram: Protection Rings
3. How the CPU Enforces It
The CPU has a register that stores the CPL (Current Privilege Level).
- When running User Code:
CPL = 3. - When running Kernel Code:
CPL = 0.
Every time the CPU fetches a “Privileged Instruction” (like CLI - Disable Interrupts), it checks:
Is CPL == 0?
- Yes: Execute it.
- No: Trigger a General Protection Fault (GPF).
The OS catches this Fault and kills the process (SIGSEGV/SIGKILL).
4. Traps vs Interrupts
How do we switch from Ring 3 to Ring 0?
| Type | Initiator | Example |
|---|---|---|
| Trap (Syscall) | Software (Intentional) | Application calls read(). |
| Exception (Fault) | Software (Error) | Application divides by zero or touches bad memory. |
| Interrupt | Hardware (External) | Network card says “Packet Arrived”. Keyboard says “Key Pressed”. |
5. Interactive: The Gatekeeper
Try to execute privileged instructions from User Mode. Goal: Don’t get killed by the OS.
6. Summary
The “User Mode” vs “Kernel Mode” distinction is not just a software convention. It is hard-wired into the silicon of the CPU. This hardware enforcement is the foundation of system stability and security.