According to http://www.linfo.org/kernel_mode.html in paragraph 7:

When a user process runs a portion of the kernel code via a system call, the process temporarily becomes a kernel process and is in kernel mode. While in kernel mode, the process will have root (i.e., administrative) privileges and access to key system resources. The entire kernel, which is not a process but a controller of processes, executes only in kernel mode. When the kernel has satisfied the request by a process, it returns the process to user mode.

It is quit unclear to me about the line,

While in kernel mode, the process will have root (i.e., administrative) privileges and access to key system resources.

How come a userspace process running not as root will have root privilege? How does it differ from userspace process running as root?

  • It turns out that not everything that you read on the internet is correct. You do not become root, when in kernel mode. Kernel mode is all powerful. In this mode it may ask it self, what user is active, shall I do what has been asked of me. If you became root, then the kernel would be everything you asked of it, this is clearly not the case. Feb 20, 2015 at 13:02

2 Answers 2


Root and non root privileges are all user space related things. For example, a root user can install an application and an ordinary user can't.

However, even the root user has some limitations. Those limitations are imposed by the design of the operating system do differentiate between user space and kernel space. For example, even dough you are a root user, you can't change the speed at which the hard disk rotates if that option isn't provided to you through the driver (you can write a driver that will allow the function, but even then you are not accessing the hardware directly but through the driver).

The reason for this is that the actual control of the hardware is all done in kernel space and the way user space accesses it is through system calls. A kernel space is not a place for a user :)

To answer your question, its not the process that gets the root privileges, its the switch to kernel mode that allows unlimited access to every system resource. However, that unlimited access is only available to the code running in kernel mode, so your process doesn't have it. Its only using the calls of the kernel code.

The code running in kernel mode has a completely unrestricted access to the system.

  • Does it mean that line is wrong? Because this is the first time I have read the word 'root' is used in discussing kernel mode.
    – Ron Vince
    Mar 28, 2014 at 15:35
  • Theoritically, every userspace process may have unlimited access to every system resource through system call, but non-root user is restricted to a list of system calls compared to root user?
    – Ron Vince
    Mar 28, 2014 at 15:42
  • @RonVince Yes, the second sentence you quoted is wrong. It's an approximation, but it's so crude that here it's grossly misleading. Mar 28, 2014 at 22:49

(I'll try to be brief.)

In theory, there are two dimensions of privileges:

  • The computer's instruction set architecture (ISA), which protects certain information and/or functions of the machine.

  • The operating system (OS) creating an eco-system for applications and communication. At its core is the kernel, a program that can run on the ISA with no dependencies of any kind.

Today's operating systems perform a lot of very different tasks so that we can use computers as we do today. In a very(, very, very) simplified view you can imagine the kernel as the only program that is executed by the computer. Applications, processes and users are all artefacts of the eco-system created by the OS and especially the kernel.

When we talk about user(space) privileges with respect to the operating system, we talk about privileges managed, granted and enforced by the operating system. For instance, file permissions restricting fetching data from a specific directory is enforced by the kernel. It looks at the some IDs assodicated with the file, interpretes some bits which represents privileges and then either fetches the data or refuses to do so.

The privileges hierarchy within the ISA provides the tools the kernel uses for its purposes. The specific details vary a lot, but in general there is the kernel mode, in which programs executed by the CPU are very free to perform I/O and use the instructions offered by the ISA and the user mode where I/O and instructions are constrained.

For instance, when reading the instruction to write data to a specific memory addres, a CPU in kernel mode could simply write data to a specific memory address, while in user mode it first performs a few checks to see if the memory address is in a range of allowed address to which data may be written. If it is determined that the address may not be written to, usually, the ISA will switch into kernel mode and start executing another instruction stream, which is a part of the kernel and it will do the right thing(TM).

That is one example for an enforcement strategy to ensure that one program does not interfere with another program ... so that the javascript on the webpage you are currently visiting cannot make your online banking application perform dubious transactions ...

Notice, in kernel mode nothing else is triggered to enforce the right thing, it is assumed the program running in kernel mode is doing the right thing. That's why in kernel mode nothing can force a program to adhere to the abstract rules and concepts of the OS's eco-system. That's why programs running in kernel mode are comparibly powerful as the root user.

Technically kernel mode is much more powerful than just being the root-user on your OS.

  • Did CPUs, in reference to privilege level in ISA, designed with the privilege of user and kernel in mind?
    – Ron Vince
    Mar 28, 2014 at 15:53
  • @RonVince Yes, kernel/user privileges (or something like it, e.g. on x86 they're called “rings”) exists in all CPUs that allow OSes with task separation (such as all modern desktop or server OSes: Unix, VMS, Windows, OS/2, Plan9, BeOS, QNX, …) to run. Mar 28, 2014 at 22:52
  • This is mostly a good answer, but the paragraph starting with “For instance, when reading the instruction to write data” is completely wrong. Either the load address is mapped for the current CPU mode, and the write goes through, or it isn't, and an exception is raised. Switching to kernel mode on a permission failure doesn't happen (it would be completely pointless anyway since it would make privileges irrelevant). Mar 28, 2014 at 22:54
  • @gilles: it is a very simple and abstract ISA i imagined for this answer, and the example means page faults, which do exist and result in a kernel trat, IIRC
    – Bananguin
    Mar 29, 2014 at 8:42
  • Your example does not describe how page faults work at all. Mar 29, 2014 at 15:39

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .