User Mode - CPU Execution Modes | OneNoughtOne

0/236

Operating SystemsCPU Execution Modes

CPU Execution Modes

LevelBeginner

Duration60 mins

TopicCPU Execution Modes

1 / 5

User Mode

The Invisible Sandbox

Every time you launch a web browser, run a game, or execute a Python script, something profound happens beneath the surface: your program enters a carefully constructed prison. Not a prison designed to punish, but one engineered to protect—both the system from your program, and your program from other programs.

This invisible sandbox is called User Mode (also known as unprivileged mode or ring 3 on x86 architectures). It is the foundational concept upon which all modern operating system security rests. Without User Mode, a single buggy application could crash your entire computer. A malicious program could read your passwords, corrupt other applications' data, or take complete control of your hardware.

User Mode is the reason modern computers don't collapse into chaos despite running dozens of programs simultaneously.

What You Will Learn

By the end of this page, you will understand: (1) Why User Mode exists and the problems it solves, (2) How processors architecturally implement User Mode restrictions, (3) What resources and operations are available vs. restricted in User Mode, (4) How User Mode affects application performance and design, and (5) Why every application developer—not just kernel developers—needs to understand this concept.

The Problem User Mode Solves

To understand User Mode, we must first understand the chaos it prevents. Early computers had no concept of privilege separation—every program ran with full access to the hardware.

Consider what happens without User Mode:

A single misbehaving program could:

Write directly to any memory address, corrupting other programs or the OS itself
Reprogram hardware devices, causing system-wide failures
Access any file on disk, including system files and other users' data
Disable interrupts, freezing the entire system
Monopolize the CPU, starving all other programs

In the early days of computing (1950s-1960s), this was reality. Programs regularly crashed entire systems. Multi-user computing was impractical because any user could accidentally (or intentionally) destroy everyone else's work.

The Mutual Distrust Principle

Modern operating systems are built on a fundamental assumption: no program can be trusted. Not because all programs are malicious, but because bugs are inevitable. Even well-intentioned code can have memory corruption bugs, infinite loops, or logic errors that could destabilize the system. User Mode implements the containment strategy that makes computing practical.

The solution: Hardware-enforced privilege levels

Operating system designers realized that software-only protection was insufficient. A malicious program could simply ignore software restrictions. The solution required hardware enforcement—building privilege separation directly into the processor's architecture.

This gave birth to the dual-mode (or multi-mode) execution model:

User Mode — Restricted privileges for running applications
Kernel Mode — Full privileges for the operating system

The processor itself enforces these restrictions. When code is running in User Mode, certain operations are physically impossible—not just discouraged, but architecturally blocked by the CPU hardware.

Key Insights from Computing History

•Programs are untrusted by default — Even benign software can have vulnerabilities or bugs that could affect system stability.
•Software protection is insufficient — Malicious code can bypass software-only restrictions; hardware enforcement is essential.
•Containment beats prevention — We can't prevent all bugs, but we can contain their damage to a single application's space.
•Privilege separation enables multi-programming — Only when programs were isolated could multiple users share one computer safely.

Defining User Mode

User Mode is the CPU execution state in which application programs run. It provides a restricted, sandboxed environment where programs can:

Execute non-privileged instructions (arithmetic, logic, data movement)
Access memory only within their allocated address space
Request OS services through controlled system call interfaces
Be preempted and controlled by the operating system

The formal definition:

User Mode is a processor execution mode characterized by reduced CPU privileges, wherein the executing code is prevented by hardware enforcement from performing operations that could affect system stability, security, or the resources of other processes.

What makes it 'user' mode?

The naming convention reflects the historical context: this is the mode in which user programs (as opposed to system programs) execute. Today, 'user' is perhaps misleading—servers, daemons, and system utilities also run in User Mode. A more accurate term might be 'application mode' or 'unprivileged mode.'

User Mode vs. Kernel Mode Summary
Aspect	User Mode	Kernel Mode
Privilege Level	Lowest (Ring 3 on x86)	Highest (Ring 0 on x86)
Hardware Access	No direct access	Full hardware control
Memory Access	Only allocated user space	All physical memory
Instruction Set	Subset (non-privileged only)	Full instruction set
Who Runs Here	Applications, libraries	OS kernel, drivers
Failure Impact	Process crash only	System crash (BSOD/panic)

The Hierarchical Privilege Model

Many architectures implement more than two privilege levels. x86 processors define four 'rings' (0-3), though most operating systems use only Ring 0 (kernel) and Ring 3 (user). Some hypervisors use Ring -1 (hardware virtualization level). ARM processors use Exception Levels (EL0-EL3). The concept remains the same: concentric layers of decreasing privilege.

Architectural Implementation

User Mode isn't an abstract concept—it's a concrete state of the processor, determined by specific hardware registers and enforced on every instruction execution. Let's examine how modern processors implement this.

The Mode Bit (Current Privilege Level)

At the heart of privilege enforcement is a small piece of processor state called the mode bit (or Current Privilege Level, CPL). This is a 2-bit field in the Code Segment register (CS) on x86, or a field in the Program Status Register (PSR) on ARM.

When the mode bit = 0 → Processor is in Kernel Mode (Ring 0)
When the mode bit = 3 → Processor is in User Mode (Ring 3)

privilege_check_pseudocode.txt
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
// Simplified processor logic for every instruction execution
function executeInstruction(instruction) {
    currentPrivilegeLevel = getCodeSegment().privilegeLevel;
    
    if (instruction.requiresKernelMode) {
        if (currentPrivilegeLevel != 0) {
            // CPU raises a General Protection Fault (#GP)
            triggerException(GENERAL_PROTECTION_FAULT);
            // Control transfers to kernel exception handler
            return;
        }
    }
    
    if (instruction.accessesMemory) {
        targetAddress = calculateEffectiveAddress(instruction);
        if (!isAddressAccessibleAt(targetAddress, currentPrivilegeLevel)) {
            // CPU raises a Page Fault or Protection Fault
            triggerException(PROTECTION_FAULT);
            return;
        }
    }
    
    // Instruction can proceed
    actuallyExecute(instruction);
}

Key insight: This privilege check happens on every single instruction. There's no performance shortcut that bypasses it. The silicon gates implementing CPL checking are part of the fundamental instruction execution pipeline.

Memory Protection Integration

The privilege level interacts with memory protection hardware:

Page Table Entries (PTEs) contain permission bits:
- User/Supervisor bit (U/S): Determines if the page is accessible in User Mode
- Read/Write bit (R/W): Controls write access
- No-Execute bit (NX): Prevents code execution from data pages
Segment Descriptors (legacy x86) contain a Descriptor Privilege Level (DPL)
Access checks combine CPL with memory permissions:
- A User Mode process (CPL=3) cannot access pages marked Supervisor-only (U/S=0)
- Even Kernel Mode accesses can be restricted by R/W and NX bits

Why Hardware Enforcement Matters

These checks are implemented in hardware gates, not software routines. A malicious program cannot simply skip the privilege check or forge a different privilege level—the wires in the CPU don't provide any path for unprivileged code to modify the CPL directly. The only way to change privilege levels is through controlled transition points (system calls, interrupts) that immediately transfer control to trusted kernel code.

What User Mode Can and Cannot Do

Understanding User Mode requires knowing its precise boundaries. What operations are unrestricted? What is absolutely forbidden? And what exists in a gray area requiring OS mediation?

Fully Permitted Operations (No OS Involvement):

User Mode code can freely execute any computation that doesn't require privileged resources:

Operations Permitted in User Mode

•Arithmetic and Logic — ADD, SUB, MUL, DIV, AND, OR, XOR, shifts, comparisons on registers.
•Data Movement — MOV instructions between registers, or between registers and permitted memory.
•Control Flow — Jumps, branches, function calls (CALL), returns (RET) within user space.
•Stack Operations — PUSH, POP on the user-mode stack.
•Floating Point Operations — All FPU instructions (ADD, SUB, MUL, DIV, trig functions).
•SIMD/Vector Operations — SSE, AVX, NEON instructions for parallel data processing.
•Memory Access to User Pages — Read/write to memory addresses mapped with user permissions.

Operations Forbidden in User Mode

•Hardware I/O — IN/OUT instructions for port-based I/O are privileged. User code cannot directly communicate with devices.
•Interrupt Control — CLI (disable interrupts), STI (enable interrupts) are forbidden. User code cannot prevent preemption.
•Memory Protection Manipulation — Loading segment registers, modifying page tables, invalidating TLB entries.
•Control Register Access — CR0, CR3, CR4 (x86) control system behavior. MOV to/from these is privileged.
•Model-Specific Registers (MSRs) — RDMSR, WRMSR access system configuration and are privileged.
•System-Wide Operations — HALT (stop CPU), LGDT/LIDT (load descriptor tables), CLTS (clear task-switched flag).
•Kernel Memory Access — Any memory access to pages marked as supervisor-only triggers a fault.

Attempting Forbidden Operations

When User Mode code attempts a privileged instruction, the CPU generates a General Protection Fault (#GP, exception 13 on x86). The processor immediately transfers control to the kernel's exception handler at a predetermined address. The kernel typically responds by terminating the offending process—this is how 'Segmentation Fault' and 'Access Violation' errors occur.

The Gray Area: Mediated Operations

Many useful operations require privileged resources but are too common to deny entirely. The solution is OS mediation via system calls:

Operation	Why It's Restricted	How User Mode Achieves It
File I/O	Requires disk hardware access	`read()`, `write()` syscalls
Network I/O	Requires NIC hardware access	`send()`, `recv()` syscalls
Process Creation	Modifies kernel data structures	`fork()`, `exec()` syscalls
Memory Allocation	Modifies page tables	`mmap()`, `brk()` syscalls
Time Access	Some clocks require privileged access	`gettimeofday()` syscall
Thread Creation	Creates kernel-scheduled entity	`clone()` syscall

This mediation pattern is fundamental: User Mode performs computation; Kernel Mode provides controlled access to resources.

Memory Isolation in User Mode

One of User Mode's most critical properties is memory isolation. Each process running in User Mode believes it has exclusive access to the entire memory space—but this is an elaborate illusion created by the operating system and hardware working together.

Virtual Address Space:

Every User Mode process sees a virtual address space, typically spanning 0x0 to some maximum (e.g., 0x00007FFFFFFFFFFF on 64-bit Linux). But this virtual space:

Is partially mapped — Only allocated regions map to physical memory
Is completely private — Process A's address 0x1000 is different from Process B's address 0x1000
Has holes — Unmapped regions trigger page faults if accessed
Has protected zones — Kernel memory is mapped but inaccessible

Converting Mermaid diagram...

Why Memory Isolation Matters:

Security — Process A cannot read Process B's passwords, encryption keys, or sensitive data.
Stability — A buffer overflow in one process cannot corrupt another process's memory.
Debugging — Pointer bugs affect only the offending process, not the whole system.
Simplicity — Programmers write code as if they own all memory; the OS handles the complexity.

The Kernel Memory Paradox:

Curiously, kernel memory is typically mapped into every process's address space (in the upper portion). But it's marked as supervisor-only in the page tables. User Mode code can see these addresses exist but cannot access them.

This design enables fast system calls—when transitioning to Kernel Mode, the kernel code is already mapped and doesn't require a page table switch. However, this also created vulnerabilities (Meltdown) that required software mitigations (KPTI/KAISER).

ASLR: Adding Unpredictability

Modern systems use Address Space Layout Randomization (ASLR) to randomize where code, heap, and stack are placed in virtual memory. This makes exploitation harder—even if an attacker finds a vulnerability, they don't know where the code they want to corrupt is located. ASLR is only possible because each process has independent virtual addressing.

User Mode and Application Design

Understanding User Mode directly impacts how applications are designed and optimized. The boundary between User and Kernel Mode has real performance and architectural implications.

The System Call Overhead:

Every system call requires:

Saving user-mode registers
Switching privilege level (mode bit change)
Jumping to kernel entry point
Validating all parameters (kernel doesn't trust user data)
Performing the operation
Preparing return value
Restoring privilege level
Returning to user code

This costs roughly 100-1000 CPU cycles per system call on modern hardware. While insignificant for occasional file reads, it becomes critical for high-frequency operations.

System Call Cost Impact Examples
Scenario	Naive Approach	Optimized Approach	Improvement
Reading 1MB file	1M × 1-byte read() calls	1 × 1MB read() call	~1000x faster
Getting current time	Syscall per timestamp	VDSO mapped clock	~10x faster
Network packet I/O	Syscall per packet	io_uring batching	~5-10x faster
Memory allocation	mmap() per allocation	User-space allocator pool	~100x faster

Design Patterns Influenced by User Mode:

Buffering — Libraries like stdio buffer multiple small operations into fewer system calls. printf() doesn't immediately call write(); it accumulates data.
Memory Pools — Instead of asking the kernel for each small allocation, allocators request large chunks and subdivide them in user space.
VDSO (Virtual Dynamic Shared Object) — Linux maps certain kernel data (like the current time) into user-readable pages, allowing 'system calls' without actual privilege transitions.
Memory-Mapped I/O — Instead of read/write syscalls, files can be mapped into user address space. Access appears as normal memory operations.
Batched I/O — Modern APIs (io_uring, Windows I/O Completion Ports) allow submitting multiple I/O requests in a single system call.

The Invisible Optimization

Most of these optimizations are invisible to application developers—they're implemented in libraries, runtimes, and language implementations. But understanding why they exist (minimizing User→Kernel transitions) helps you recognize when you might be inadvertently defeating these optimizations, like calling fflush() after every write.

User Mode in Different Contexts

User Mode concepts apply universally across operating systems and architectures, though terminology and implementation details vary.

x86/x64 Architecture:

Uses protection rings (Ring 0-3, typically only 0 and 3 used)
CPL stored in CS segment register
Page tables include U/S (User/Supervisor) bit
Transition via INT, SYSCALL, or SYSENTER instructions

ARM Architecture:

Uses Exception Levels (EL0-EL3)
EL0 = User Mode, EL1 = Kernel, EL2 = Hypervisor, EL3 = Secure Monitor
'User' translation table base register (TTBR0_EL1) for user mappings
Transition via SVC (Supervisor Call) instruction

RISC-V Architecture:

Defines Machine (M), Supervisor (S), and User (U) modes
Mode stored in mstatus/sstatus register
Deliberately simple, clean-slate design
Transition via ECALL instruction

Windows User Mode

•All Win32 applications run in User Mode
•User-mode drivers exist for printers, etc.
•NTDLL.dll provides syscall interface
•WoW64 enables 32-bit apps on 64-bit
•AppContainer provides additional sandboxing
•UWP apps have even more restrictions

Linux/Unix User Mode

•All processes start in User Mode (except init)
•libc provides syscall wrappers
•LD_PRELOAD allows syscall interception
•seccomp filters available syscalls
•Namespaces/cgroups extend isolation
•SELinux/AppArmor add mandatory access control

Browser Sandboxing

Modern browsers implement additional User Mode sandboxing beyond OS-level protection. Chromium's renderer processes run with severely restricted syscall capabilities (via seccomp on Linux or sandboxed tokens on Windows). Even if an attacker exploits a browser vulnerability, the compromised renderer can't access files, network, or most OS resources—demonstrating that User Mode restrictions can be layered.

Summary: User Mode

User Mode is far more than a technical detail—it's the foundation that makes modern, multi-process computing possible. Let's consolidate our understanding:

Key Takeaways

•User Mode is a hardware-enforced sandbox — The CPU itself prevents unprivileged code from accessing protected resources.
•Privilege is encoded in processor state — The mode bit (CPL) determines what instructions can execute and what memory can be accessed.
•Violations trigger exceptions — Attempting forbidden operations causes CPU faults that transfer control to the kernel.
•Memory isolation is per-process — Each process has a private virtual address space, invisible to others.
•System calls bridge the gap — User Mode accesses privileged resources through controlled kernel interfaces.
•Performance implications are real — Understanding mode transitions helps design efficient applications.
•Layered isolation is possible — Modern systems add sandboxing layers on top of basic User Mode restrictions.

Looking ahead:

User Mode is only half the story. The next page explores Kernel Mode—the privileged execution state where the operating system runs, with full access to hardware and the ability to do anything the processor is capable of. Understanding both modes is essential to grasping how operating systems maintain control while allowing applications to function.

Page Complete

You now understand User Mode: the restricted execution environment where all applications run, protected by hardware-enforced privilege checks. This sandbox prevents any single application from destabilizing the entire system. Next, we'll explore the unrestricted Kernel Mode and understand the full privilege architecture.