A running program can execute millions of CPU instructions every second.

But not every instruction should be available to every program.

Imagine allowing a text editor, browser tab, or downloaded application to:

A small bug could crash the entire computer. A malicious program could read passwords from another application or take complete control of the system.

To prevent this, modern CPUs support different privilege levels.

A privilege level determines which instructions and hardware resources the currently running code is allowed to access.

The operating system uses these levels to separate ordinary applications from trusted kernel code.

Although processors may support several privilege levels, operating-system discussions usually focus on two:

Most application code runs in user mode.

The operating-system kernel runs in kernel mode.

This separation creates a protection boundary between applications and the hardware.

The protection boundary is not a software layer you can call into like a library. It is a line the processor itself watches. Applications cannot simply cross this boundary whenever they want. They must use controlled mechanisms provided by the operating system.

User mode is the restricted execution mode used by ordinary applications.

A program running in user mode can perform normal calculations, call functions, manipulate its own memory, and execute most common CPU instructions.

However, it cannot directly perform operations that could affect the entire system.

For example, user-mode code normally cannot:

If a user-mode program attempts an illegal operation, the CPU does not simply continue.

It detects the violation and transfers control to the operating system. The operating system may terminate the program or report an error.

This is why a crashing application usually does not crash the entire computer.

The failure is contained within the process.

Kernel mode is the privileged execution mode used by the operating-system kernel.

Code running in kernel mode can access protected CPU instructions and system resources.

The kernel needs this level of control because it is responsible for managing the machine.

It must be able to:

Kernel mode provides power, but it also introduces risk.

A bug in a normal application may crash one process. A bug in kernel code can corrupt system state, expose sensitive data, or crash the entire operating system.

This is why the amount of code running with kernel privileges should be limited and carefully tested.

Privilege levels are not merely rules that applications are expected to follow.

They are enforced by the processor.

The CPU keeps track of the privilege level of the code currently executing. Before running a protected instruction or accessing protected memory, it checks whether the current level has permission.

Conceptually, the CPU performs a check like this:

The check happens on every attempt, and the program has no say in the outcome. This hardware enforcement is essential.

If privilege restrictions were implemented only as software conventions, a malicious program could simply ignore them.

Some CPU instructions are classified as privileged instructions.

Only trusted code running at an appropriate privilege level can execute them.

Examples include instructions that:

The exact instructions depend on the processor architecture.

An application rarely needs to know their names. The important point is that the CPU prevents ordinary programs from using them directly.

Suppose a user program attempts to disable interrupts. If it succeeded, the operating system might stop receiving timer events, device notifications, or other critical signals.

The processor therefore rejects the instruction when it is executed in user mode.

Privilege levels also help protect memory.

The operating system marks different memory regions with permissions such as user-readable, user-writable, executable, and kernel-only.

When a program accesses memory, the CPU checks both the address and the current privilege level.

A user process may be allowed to access its own code, stack, and heap, but not the kernel’s memory.

All four regions belong to the same address space. Kernel memory is not stored somewhere unreachable. Its addresses sit alongside the others and carry a permission the process cannot satisfy.

If the application attempts to access a kernel-only address, the processor raises a fault.

This hardware protection prevents applications from directly reading or modifying sensitive operating-system data.

Applications still need to perform operations that require privileged access.

For example, a program may need to:

The application cannot perform the underlying hardware operations directly.

Instead, it asks the operating system to perform the operation on its behalf.

The basic flow is:

Steps 3 and 5 are the mode changes, and they come in a pair. Every entry into the kernel has a matching return, so the elevated privilege lasts only for the duration of the request.

This transition is controlled.

The application cannot choose an arbitrary location inside the kernel and begin executing privileged code. It can only enter through predefined operating-system entry points.

We will study these entry points in detail when we cover system calls.

Consider a program that reads a configuration file:

The program runs in user mode.

It cannot directly locate disk blocks or send commands to the storage controller.

Instead, the program requests file access through the operating system.

The operating system then checks whether:

If the request is valid, the kernel communicates with the file system and storage device, then returns the result to the application.

The application receives access to the file without gaining direct control over the disk.

This is the main benefit of the privilege boundary:

Applications can use protected resources without receiving unrestricted control over them.

Privilege levels protect the kernel, but application isolation also depends on memory mappings configured by the operating system.

Suppose two applications are running: Process A is a code editor, and Process B is a password manager.

Both run in user mode.

User mode alone does not distinguish one application from another. The operating system creates separate memory mappings for each process.

When Process A is running, the CPU uses Process A’s memory mappings. When Process B runs, it uses Process B’s mappings.

As a result, Process A cannot normally access Process B’s private memory, even though both run at the same privilege level.

This protection comes from three mechanisms working together, and no single one of them is enough:

Privilege levels alone would leave the code editor and the password manager equally free to read each other, since both run in user mode. The separate memory mappings are what keep them apart, and the access rules decide what each may reach through the kernel.

Some processor architectures support more than two privilege levels.

The x86 architecture, for example, defines four privilege rings, but mainstream operating systems use only the two at the extremes:

Rings 1 and 2 exist in the hardware and are usually not used by mainstream operating systems for normal application execution, which is why two levels are enough for almost every discussion.

Other architectures use different terminology. For example, ARM processors define exception levels rather than x86-style rings.

The names differ, but the core idea remains the same: trusted system code executes with more privileges than ordinary applications.

For this course, we will usually use the simpler terms user mode and kernel mode.

No.

This is a common misconception.

A program launched by the root user still normally executes in user mode.

The root user has broad permissions granted by the operating system, but the process is still restricted by the CPU’s privilege level.

For example, a root-owned application cannot directly modify processor control registers using arbitrary user-space instructions.

It must still request privileged operations through the kernel.

These are two different ideas:

Root has more operating-system permissions, but root applications do not automatically execute as kernel code.

Moving between user mode and kernel mode requires additional work compared with an ordinary function call.

The processor must transfer control safely, switch execution context, and later return to the application.

The kernel must also validate the request because user-space data cannot be trusted blindly.

This does not mean kernel transitions should always be avoided. Applications need them to interact with files, networks, devices, and other protected resources.

However, system software often tries to reduce unnecessary transitions by buffering work or processing multiple operations together.

For example, writing one byte at a time may require many operating-system requests, while writing a larger buffer can reduce the number of transitions.

We will explore this trade-off later when studying system calls and I/O.

Suppose a program attempts to access protected memory:

The address does not refer to valid memory owned by the process.

When the CPU attempts the access, it detects that the operation is not allowed and raises a fault.

The operating system handles the fault and usually terminates the process.

On Linux, the program may report:

The important sequence is:

The work is split between two parties. The CPU detects the violation. The operating system decides how to respond.

Privilege levels may appear to be a low-level hardware topic, but they affect everyday backend systems.

Whenever a service reads a file, opens a socket, creates a thread, or allocates memory, it crosses operating-system boundaries in some form.

Understanding privilege levels helps explain:

It also provides the foundation for understanding system calls, interrupts, process isolation, and virtual memory.

Think of user mode as a protected workspace.

Applications can calculate, manipulate their own data, and execute normal instructions inside that workspace.

When they need access to a protected resource, they must ask the kernel.

The kernel acts as a trusted gatekeeper. It receives the application request, validates the permissions and arguments, accesses the protected resource on the application's behalf, and returns a controlled result.

The application receives the service it needs without gaining full control over the machine.

Modern processors support privilege levels to prevent ordinary applications from controlling the entire computer.

Applications normally run in user mode, where they can execute common instructions but cannot directly access protected memory, hardware, or privileged CPU operations.

The operating-system kernel runs in kernel mode, where it has the authority required to manage memory, processes, devices, and other system resources.

The CPU enforces this separation in hardware. When an application needs a privileged operation, it must request help from the operating system through a controlled transition.

The most important idea is:

Privilege levels allow applications to use the computer without giving them unrestricted control over it.