Why Kernel Space Matters: Understanding User vs Kernel Mode in Linux

Kernel Space and User Space

In a 32‑bit operating system the virtual address space is 4 GiB (2³² bytes). The upper 1 GiB (addresses 0xC0000000‑0xFFFFFFFF) is reserved for the kernel and is mapped identically into every process; the lower 3 GiB (0x00000000‑0xBFFFFFFF) is the user portion that each process can use for its own code, data, heap and stack.

Why the Separation Exists

CPU architectures define privileged (ring‑0) and non‑privileged (ring‑3) instruction sets. Instructions that can modify page tables, I/O ports, or the system clock must only be executed in privileged mode, otherwise a buggy or malicious program could crash or compromise the whole system. The kernel runs in ring‑0 and therefore has unrestricted access; user programs run in ring‑3 and are limited by the hardware.

Kernel Mode vs User Mode

When a thread executes in kernel mode the CPU allows any memory address and any I/O port to be accessed. In user mode the MMU checks that the accessed virtual address is mapped with user permissions and the I/O Permission Bitmap restricts port I/O. Violations raise a fault and the process is terminated.

Transition from User Space to Kernel Space

All privileged operations (disk I/O, memory allocation, network I/O, etc.) are performed by the kernel. An application requests such services through a system call. The typical sequence is:

Application places arguments in registers or a user‑mode buffer and executes a special instruction (e.g., int 0x80 on x86 or syscall on x86‑64).

CPU switches to ring‑0, saves the user‑mode stack pointer, and switches to the kernel‑mode stack associated with the current process.

The system‑call handler validates arguments, performs the requested operation in kernel space, and copies any result back to the user buffer.

The kernel restores the saved user‑mode registers and stack pointer, then returns to user mode.

Because each process has two stacks, the transition is safe: the user‑mode stack cannot be corrupted by kernel code, and the kernel‑mode stack is not visible to user code.

Three mechanisms can cause a switch to kernel mode:

System calls (explicit request from a program).

Software interrupts (e.g., int instructions used for legacy system calls).

Hardware interrupts (asynchronous events from devices).

Overall Linux Execution Contexts

The Linux execution environment can be viewed as three layers:

Hardware.

Kernel space, which includes the core kernel, device drivers, and interrupt handlers.

User space, where ordinary applications run.

Within kernel space there are two distinct contexts:

Process context : code runs on behalf of a specific process and can sleep, schedule, and access the process’s resources.

Interrupt context : code runs in response to an interrupt, is not associated with any process, cannot sleep, and must finish quickly.

Interrupt Service Routines (ISRs) execute in interrupt context, perform minimal work, and then return control to whatever code was interrupted.

Summary

Separating kernel and user spaces, together with privileged CPU rings, provides isolation that protects system stability and security. Understanding the address layout, the two execution modes, the stack‑switching mechanism, and the three execution contexts (user, process‑kernel, interrupt‑kernel) is essential for studying operating‑system internals.