Kernel Mode
Privileged execution: the CPU will honor instructions that touch control registers and I/O.
Level: intermediate
What is it?
Kernel mode is a processor privilege state in which trusted OS code can execute privileged instructions and manage protected CPU state. On common systems, kernel code controls page tables, interrupt configuration, scheduling, and hardware interfaces subject to CPU and platform rules.
Why does it matter?
Privileged instructions must be tightly controlled because mistakes can destabilize or compromise the entire machine. The operating system confines most application logic to user mode and enters kernel mode only through defined events.
Mental model
Kernel mode is not a separate computer; it is a more privileged execution state on the same CPU. A transition changes what the CPU permits, while the kernel still must follow correct invariants and handle unsafe input.
How it works
- System calls, exceptions, and interrupts are controlled entry paths into privileged handling code.
- The processor and memory-management unit enforce permissions; software cannot safely simulate these protections alone.
- Kernel-mode bugs can corrupt shared state or crash the system, so kernel code needs stronger validation and review.
- The return path restores the user context or schedules a different runnable thread.
- Privilege level and process identity are distinct: a kernel thread can run without a user process's ordinary address space.
Steps
- A thread runs application code in user mode.
- A timer interrupt occurs and transfers control to the kernel's interrupt handler.
- The kernel records state and may decide another thread should run.
- The return path restores the chosen thread and resumes its execution with the appropriate privilege.
Real-world usage
- Explaining interrupt-driven scheduling and protected device access.
- Reasoning about why kernel drivers require stronger trust.
- Debugging user/kernel boundary issues in low-level code.
Common mistakes
- Equating kernel mode with administrator permissions inside an application; these are different concepts.
- Assuming kernel code can ignore validation because it is privileged.
- Assuming every kernel-mode entry is caused by a system call; interrupts and exceptions are also entry paths.
Interview questions
What is the risk of a kernel-mode bug?
It can affect shared kernel state, bypass isolation, or crash the system, unlike a typical contained user-process failure.
Does a system call always imply a context switch to another process?
No. It changes privilege and enters the kernel, but the same thread may continue after the call; scheduling another thread is a separate decision.