When you open a browser, play music, or run a C++ program, the CPU executes instructions for those applications.
It also executes instructions for the operating system.
But these instructions do not all run with the same permissions.
A browser can calculate numbers and update its own data. It cannot freely rewrite the kernel’s memory or take control of the entire computer.
How does the computer enforce that difference?
The answer begins with user mode and kernel mode: different execution privileges that help separate ordinary applications from the code responsible for managing the system.
In this tutorial, we will explain what these modes mean, why they exist, and how applications cross this boundary to request operating system services.
1. What Does “Mode” Mean?
A mode is an execution state of the processor that determines which operations the currently running code is allowed to perform.
A privilege is permission to perform a protected operation.
User mode provides restricted privileges for ordinary application code. Kernel mode provides the privileges needed by the operating system’s core.
These are not two separate processors. The same processor can execute application instructions in user mode and later execute kernel instructions in kernel mode.
On a computer with multiple CPU cores, different cores can execute user code and kernel code at the same time. There is no single switch that places the entire computer in one mode.
The important question is: what privileges apply to the code executing here, right now?
2. Why Do We Need Different Privileges?
Imagine that every application could modify any part of memory, change the processor’s protection settings, or issue unrestricted commands to devices.
A small programming mistake could damage the operating system. A malicious application could interfere with other programs or disable protections intended to stop it.
For example, a text editor might calculate the wrong memory address because of a bug. If that address points to protected memory, the system needs a way to block the access.
This protection cannot depend on the application voluntarily following the rules.
The operating system establishes restrictions, and processor hardware helps enforce them. This cooperation creates a boundary between ordinary program execution and system management.
3. What Can Programs Do in User Mode?
User mode is where ordinary application code normally runs.
Applications can perform arithmetic, compare values, execute loops, call their own functions, and read or write memory they are permitted to access.
A process is a running instance of a program, together with the resources and execution state managed for it by the operating system.
Each process normally has its own virtual address space: the set of memory addresses through which it accesses its code and data.
Application code cannot freely access memory reserved for the kernel or another process. Operating systems can allow selected memory to be shared, but that sharing is controlled.
This separation helps contain application failures. A browser process crashing does not normally mean that the entire operating system must crash. Microsoft explains this separation in its user-mode and kernel-mode documentation.
User mode still allows useful work to happen directly on the CPU. The kernel does not need to approve every addition, comparison, or ordinary function call.
4. What Can the Kernel Do in Kernel Mode?
The kernel is the core of the operating system. It manages resources and enforces essential rules about how programs use them.
To do this, it needs access to protected processor operations.
A privileged instruction is an instruction whose execution requires an appropriate processor privilege level. Examples include instructions used to change protected memory-management settings or control certain interrupt behavior.
The exact instructions and restrictions depend on the processor architecture.
Kernel mode gives kernel code the authority required for system management. That authority also makes mistakes more dangerous.
A faulty device driver, meaning software that communicates with a particular device or device class, can damage critical system data if it runs in kernel mode. Some drivers instead run in user mode, depending on the operating system and driver design. Microsoft’s documentation describes these driver distinctions and failure risks.
5. How Does the Hardware Enforce the Boundary?
The processor tracks the current privilege mode as part of its execution state.
When code attempts a protected operation, the hardware checks whether the operation is permitted.
Memory protection also depends on structures configured by the operating system. In systems using virtual memory, page tables describe how virtual addresses map to physical memory and include access permissions.
The memory management unit, or MMU, is hardware that translates addresses and checks the relevant memory permissions.
If application code attempts a prohibited memory access, the hardware raises an exception: an event caused by the instruction being executed that requires special handling.
The operating system can then respond. For an invalid application access, that response may ultimately terminate the process.
Some exceptions are recoverable, so an exception does not automatically mean that a program must crash.
The essential point is that an ordinary load or store instruction does not bypass protection simply because the program supplies a particular address.
6. How Does an Application Request a Kernel Service?
Applications still need files, network connections, and other resources managed by the operating system.
They request these services through system calls.
A system call is a controlled interface through which an application requests work from the kernel. In Linux, applications commonly reach this interface through a library function: reusable code that prepares and submits the request. The Linux system-call manual explains this relationship.
The application identifies the requested operation and supplies its arguments, meaning the values needed for that operation.
An architecture-specific instruction then transfers execution through an established kernel entry mechanism.
The application does not simply gain permission to continue running its own code in kernel mode.
Execution moves to a kernel entry point configured by privileged system software. The kernel examines the request, checks the supplied information, and decides whether the operation is allowed.
When the request finishes, execution can return to application code in user mode with a result or an error.
7. Example: Reading a File
Consider a text editor reading an existing file.
First, application code requests that the file be opened. The kernel resolves the requested file and checks the applicable access permissions.
On a successful Linux open operation, the application receives a file descriptor: a small integer that identifies the open file within that process.
The application then requests a read, supplying the descriptor, a destination buffer, and the amount of data wanted. A buffer is a region of memory used to hold data temporarily.
The kernel checks the request and obtains the data. If the data is already available in memory, a storage-device operation may be unnecessary. Otherwise, the system arranges the required device work.
For an ordinary read, the kernel places the available data into the application’s buffer and returns a result.
The editor resumes in user mode and processes the text.
Opening and reading are separate operations in this simplified example. One visible application action can involve several system calls.
Throughout the sequence, the editor asks for specific services. It does not receive unrestricted control over the storage device.
8. System Calls Are Not the Only Way into the Kernel
Hardware events can also cause kernel code to run.
An interrupt is an event, such as a timer signal or device notification, that can redirect processor execution to a handler. A handler is code responsible for responding to that event.
For example, a device may signal that an operation has completed.
An exception can also transfer execution to a handler. Examples include an attempted prohibited instruction or a memory access requiring operating system attention.
These events have different starting points:
- A system call deliberately requests a service.
- A hardware interrupt reports an event.
- An exception arises from the current instruction.
When one of these events transfers execution from application code to the kernel, the processor enters the appropriate privileged state. An event occurring while kernel code is already running does not necessarily change the privilege mode.
9. A Mode Switch Is Not Necessarily a Context Switch
A mode switch changes the privilege level of execution, such as moving from user mode into kernel mode.
A context switch changes which thread is running by saving one thread’s execution state and restoring another’s. A thread is a sequence of execution within a process.
These events can happen together, but they are different.
Suppose an application makes a system call that the kernel can complete immediately. Kernel code may handle the request on behalf of the same thread and return directly to it.
There has been a mode switch without switching to another thread.
If the request must wait for storage, the operating system may run another thread meanwhile. That introduces a context switch as well.
Entering the kernel therefore does not automatically mean that another application starts running.
10. Administrator Access Is Not Kernel Mode
An administrator account has broad permissions under operating system rules.
On Linux and other Unix-like systems, the traditional administrator account is called root.
However, a program running as root still normally executes its application instructions in user mode. The same distinction applies to an application launched with administrator privileges on Windows.
The account’s permissions influence which requests the kernel allows. They do not automatically change the CPU privilege mode of the application’s instructions.
For example, an administrator may be allowed to change a protected system setting. The application still requests that change through operating system interfaces.
User identity and CPU privilege mode are separate concepts.
11. How This Connects to RISC-V
“User mode” and “kernel mode” describe a common operating system distinction. Processor architectures do not all implement it with exactly two hardware privilege levels.
RISC-V’s standard privileged architecture defines three principal levels: User mode, Supervisor mode, and Machine mode, abbreviated U, S, and M.
In a typical RISC-V system running an operating system such as Linux, application code runs in U-mode and the kernel runs in S-mode.
M-mode has higher privilege and commonly runs low-level firmware: software that initializes the platform or provides basic machine services.
Not every RISC-V processor implements all three modes. M-mode is mandatory; simpler implementations may omit the others. The RISC-V privileged specification defines these levels and their intended uses.
The broader principle remains the same: different parts of the software system receive different levels of authority.
12. Conclusion
User mode and kernel mode establish an essential boundary between applications and the operating system’s core.
Applications execute ordinary instructions with restricted privileges. The kernel uses greater privileges to manage resources and enforce protection.
System calls let applications request services through controlled entry points. Interrupts and exceptions provide other reasons for kernel code to run.
A mode switch does not necessarily switch threads, and administrator access does not turn application code into kernel code.
These protections do not eliminate every bug or security vulnerability. They give the system a foundation for containing failures and controlling access.
With this boundary understood, the next question becomes more concrete: how does a system call carry a request from application code into the kernel and bring the result back?