Linux User-mode Kernel Mode

Link: http://jakielong.iteye.com/blog/771663

 

1. Differences between the concepts of user State and kernel state

What is the user State and kernel state? These two basic concepts have never been fully understood before, the root cause is that most of the time we focus on programming and focus on implementing functions and code logic. Let's look at an example:

1) Example

 

C code  

1. Void testfork (){
2. If (0 = fork ()){
3. Printf ("create new process success! \ N ");
4. }
5. Printf ("testfork OK \ n ");
6. }

 

 

This code is very simple. From a functional point of view, it means that a fork () is actually executed to generate a new process. From a logic point of view, it is determined that if fork () if the return value is 0, the related statement is printed. Then, a complete testfork () function is executed. The execution logic and functions of the Code are so simple. There are a total of four lines of code that can be executed in one sentence from top to bottom. It cannot be seen that there is a concept of user State and process state.

If we look at the previous two static observations, we can also look at the code from a dynamic perspective, that is, the process of loading and executing the code after it is converted into a CPU-executed command, in this case, this program is a sequence of dynamically executed commands. The Code loaded is closely related to the operating system.

 

2) privileged level

Anyone familiar with Unix/Linux systems knows that fork's work is actually done by calling the system. The specific work is implemented by sys_fork. In fact, whether it is Unix or Linux, for any operating system, creating a new process is a core function, because it requires a lot of bottom-layer meticulous work, consuming the physical resources of the system, for example, allocating physical memory, copying related information from the parent process, copying the page Directory and page table of setting pages, etc. These obviously cannot be done by any program, so the concept of privilege level is naturally introduced. Obviously, the most critical power must be implemented by High-level programs, so that centralized management can be achieved and access and use conflicts of limited resources can be reduced.

The privileged level is obviously a very effective way to manage and control program execution. Therefore, the hardware provides a lot of support for the privileged level. For intel X86 architecture CPUs, there is a total of 0 ~ Three or four privileged levels, with the highest level 0 and the lowest level 3. When executing each command on the hardware, the system checks the privileged level of the command, related concepts include CPL, DPL, and RPL. The hardware has provided a set of privileged-level usage mechanisms, and the software is naturally a matter of good use. This is what the operating system wants to do. For Unix/Linux, only level 0 and Level 3 are used. That is to say, in Unix/Linux systems, a command running at the level 0 privilege level has the highest power that the CPU can provide, A command that works at three levels of privilege has the lowest or most basic power provided by the CPU.

 

3) user and Kernel

Now we can better understand the user State and kernel state from the perspective of privileged scheduling. When the program runs on a three-level privileged level, it can be called running on the user State, because this is the lowest privilege level, it is the privileged level for normal user processes to run, and most of the programs that most users directly face are running in the user State; otherwise, when the program runs at the zero privilege level, it can be called running in the kernel state.

Although there are many differences between programs in user mode and kernel mode, the most important difference lies in the difference in privilege level, that is, the difference in power. The program running in the user State cannot directly access the data structure and program of the operating system kernel. For example, testfork () in the preceding example cannot directly call sys_fork (), because the former is a user-State program, while sys_fork () is a kernel-State program.

When we execute a program in the system, most of the time is running in the user State, when the operating system is required to help complete some work that it does not have the power and ability to complete, it will switch to the kernel state. For example, testfork () initially runs under the user State process, when it calls fork () and finally triggers the execution of sys_fork (), it switches to the kernel state.

 

2. Conversion of user and kernel states

1) User-mode switch to kernel-mode

A. System Call

This is a way for a user-state process to actively switch to the kernel state. the user-state process applies to use the service programs provided by the operating system through system calls to complete the work, such as fork () in fact, a system call is executed to create a new process. The core of the system call mechanism is to use an interrupt that is especially open to users by the operating system, for example, the int 80 h interrupt of Linux.

B. Exceptions

Some unknown exceptions occur when the CPU runs a program in the user State. In this case, the current running process is triggered to switch to the kernel-related program that handles the exception, it is also switched to the kernel state, such as a page missing exception.

C. Peripheral Device interruption

After the peripheral device completes the user request, it sends an interrupt signal to the CPU, at this time, the CPU will suspend the execution of the next command to be executed and then execute the processing program corresponding to the interrupt signal. If the previously executed command is a user-State program, the conversion process naturally changes from user to kernel. For example, after the hard disk read/write operation is completed, the system switches to the hard disk read/write Interrupt Processing Program for subsequent operations.

 

These three methods are the most important way for the system to switch from the user State to the kernel state at runtime. system calls can be considered as actively initiated by the user process, exceptions and peripheral device interruptions are passive.

 

2) specific switchover operations

From the trigger method perspective, we can consider that there are three different types mentioned above, but from the final completion of switching from the user State to the kernel state, the key steps involved are completely consistent and there is no difference. They are equivalent to executing an interrupt response process, because system calls are actually implemented by the interrupt mechanism, the handling mechanism of exceptions and interruptions is basically the same, and the specific differences between them are not described here. The details and steps of the interrupt processing mechanism are not analyzed too much here. The steps involved in switching from user mode to kernel mode include:

[1] extract the ss0 and esp0 information of the kernel stack from the descriptor of the current process.

[2] use the kernel stack pointed to by ss0 and esp0 to save the CS, EIP, eflags, SS, and ESP information of the current process.

The process also completes the switching from the user stack to the kernel stack, and saves the next

Command.

[3] load the Cs and EIP information of the interrupt processing program previously retrieved by the interrupt vector into the corresponding register and start

When the interrupt processing program is executed, the program in the kernel state is executed.