Architectures of Trust: Kernel Mode vs. User Mode

The Need for Protection: CPU Modes

Modern computer systems run multiple programs concurrently, alongside the critical Operating System (OS) itself. To prevent errors or malicious actions in one program from corrupting the OS or other programs, the CPU enforces different levels of privilege, known as execution modes. The two most fundamental modes are Kernel Mode and User Mode.

This separation relies on hardware support from the CPU, which understands these modes and restricts operations accordingly. The OS utilizes this hardware feature to maintain system stability and security.

Memory (RAM) Segregation

A primary goal of these modes is memory protection. The system's RAM holds both the essential OS code and data (the kernel) and the code/data for all running applications user processes). If any process could arbitrarily read or write any memory location, chaos would ensue.

Therefore, the OS, in conjunction with the CPU's Memory Management Unit (MMU - though we simplify this in the simulation), divides the RAM's address space:

• A specific range is designated as Kernel Space. Only code running in Kernel Mode can typically access this memory directly.
• Other ranges are allocated as User Space for individual applications. Code running in User Mode is generally confined to its own allocated User Space addresses.

In the simulation below, notice the distinct memory ranges labeled Kernel Space (e.g., 0x0000-0x7FFF) and User Space (e.g., 0x8000-0xFFFF). The CPU's current mode dictates which space(s) it can safely access.

Kernel Mode (Privileged / Supervisor Mode)

• Highest Privilege: When the CPU operates in Kernel Mode, it has complete and unrestricted access to all system resources.
• Full Memory Access: It can read/write any location in RAM, including both Kernel Space and the User Space of all running processes.
• All CPU Instructions: It can execute the full instruction set of the CPU, including special privileged instructions necessary for core system management.
• Direct Hardware Control: It can directly communicate with and control hardware devices (disks, network cards, timers, etc.).
• Who Runs Here?: The core OS kernel code executes in this mode.

In the simulation, instructions marked (K) require the CPU to be in Kernel Mode.

User Mode (Unprivileged / Restricted Mode)

• Limited Privilege: When the CPU operates in User Mode, its capabilities are intentionally restricted by the hardware.
• Restricted Memory Access: It can typically only directly access the memory addresses within its own allocated User Space. Attempts to directly access Kernel Space memory or the memory of other user processes will usually cause a hardware exception (fault).
• Restricted Instructions: It cannot execute privileged CPU instructions. Attempting to do so also causes a hardware fault.
• No Direct Hardware Access: It cannot directly interact with hardware devices.
• Who Runs Here?: Most applications (web browsers, text editors, games, utilities) run in this mode.

In the simulation, trying to run a (K) instruction or access Kernel Space memory (e.g., addresses below 0x8000) while the `Mode` indicator shows User will result in a `PRIVILEGE VIOLATION` error.

The Bridge: System Calls (Syscalls)

Since User Mode applications cannot perform privileged operations directly, they need a secure mechanism to request these services from the OS kernel. This mechanism is the System Call.

• A User Mode program prepares its request (e.g., what file to read, where to put the data) and then executes a special, non-privileged CPU instruction (often called SYSCALL, SYSENTER, or similar, simulated as SYSCALL_SWITCH).
• This instruction causes a hardware trap (a controlled type of interrupt), which forces the CPU to:
  1. Switch from User Mode to Kernel Mode.
  2. Save the current execution context (like the address of the instruction after the syscall).
  3. Jump execution to a specific, predefined entry point within the kernel's code (the syscall handler).
• The kernel's syscall handler determines which service was requested, validates parameters (e.g., does the process have permission to read that file?), performs the action using its kernel privileges, and potentially prepares results to return to the user program.

In the simulation, SYSCALL_SWITCH triggers this transition. Notice how it changes the mode and jumps execution to the kernel's starting address (0x0000).

Returning Control: From Kernel to User

Once the kernel has completed the requested service (or handled an interrupt), it needs to return control back to the User Mode program that was interrupted.

• The kernel executes a special, privileged instruction (like IRET, SYSEXIT, or similar, simulated as SYSCALL_RETURN).
• This instruction causes the CPU to:
  1. Switch from Kernel Mode back to User Mode.
  2. Restore the saved execution context of the user program, crucially setting the instruction pointer back to where the user program should resume (usually the instruction immediately following the original syscall).

In the simulation, SYSCALL_RETURN performs this switch back to User Mode and jumps execution to the address that was saved when the corresponding SYSCALL_SWITCH occurred.