Super User is a question and answer site for computer enthusiasts and power users. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

what is the difference between user mode and kernel mode? why it need a context switch when switch between the 2?

share|improve this question

migrated from Mar 26 '11 at 9:55

This question came from our site for professional and enthusiast programmers.

My answer relates to Linux because that's what I know, but it should be equally correct for most, if not all, versions of Unix.

User mode is where all processes that aren't part of the kernel (aka "non-kernel processes") run. In user mode, a process can only directly access its own memory, by default. This is to protect processes from each other and to try to prevent a bug in one process causing another process to crash. It also helps to enforce security, since a low-privilege process cannot directly access the memory of a process running as another user, which might contain confidential data such as credit card details.

However, there are some operations in the kernel that have to access the whole system memory - for example, creating new processes. For this, kernel mode is needed, because that can access any virtual or physical address that is physically accessible. (For the purposes of this answer I am ignoring hypervisors, which complicate this picture slightly.)

Switching between user mode and kernel mode may require a context switch, but only because of long-standing convention, not because it's absolutely necessary. Source:

share|improve this answer

Assuming x86 architecture:

User mode:

  • The virtual memory scheme is in effect. In user mode, memory addresses are mapped to physical addresses via page tables. So, when a user mode program accesses memory in memory location 0x0001000 for example, it is likely redirected via the virtual memory mechanism to a completely different address. This also controls access to hardware that is accessed via memory locations just like RAM, such as APIC registers, video RAM, etc. That's why a user mode process can't "break out of its shell" and change the memory locations where other programs live.

  • The I/O privilege mechanism is in effect. This affects certain hardware that uses "I/O ports" (no relation to TCP/IP ports), such as legacy PIC and PIT hardware, CMOS memory, etc. User mode can only access I/O ports allowed to by the "IOPL bitmap", can't disable interrupts, and can't change the IOPL.

  • Privileged CPU instructions will cause an exception if executed. This includes instructions for setting up page tables and other things.

Kernel mode:

  • The virtual memory scheme is not in effect. When a CPU reads memory, the address it asks for is the address it gets. It is, in other words, "flat."

Yes, it's totally possible for a process in kernel mode to overwrite other processes or code in memory, such as critical kernel structures or device drivers.

  • The I/O privilege mechanism is not effect. The CPU can access any I/O port without restriction, and set the IOPL for user mode.

  • All privileged instructions can be executed without causing an exception.

A "context switch" is needed because whenever the x86 CPU is running a program, a lot of the current state of that program at a given moment exists in its registers, in addition to RAM locations it might be using for variables and temporary storage.

So, if we want the CPU to suddenly jump elsewhere, and then return to what it was doing before, it's necessary to save all the CPU registeres so they can be restored before the jump back.

share|improve this answer

The kernel is responsible for managing the system's resources (scheduling, memory management, networking etc). The kernel runs in a protected context called ring 0 to prevent it from modification by unprivileged users.

Applications run in user mode (ring 3), and switch context when it executes a system call to requests a service from the kernel.

share|improve this answer

You must log in to answer this question.