Linux kernel State, user profile, and INTELCPU privilege level--ring0-3

One, the modern operating system permissions separation:

Modern operating systems are generally divided into kernel State and user state at least. A generic application typically runs in a user state, and when an application invokes a system call, it executes kernel code, which is now in the kernel state. In general, applications are not allowed to enter the kernel state, but need to apply to the OS because the kernel state has higher privileges. So when the program is running, there are actually two stacks, one in the user state, and one in the kernel state. They communicate between them according to the operating system rules.

Two, the user state to switch to the kernel state of three ways:

1, the system calls, that is, the application uses the interface provided by the OS to invoke kernel functions. such as the x86 platform of the int 80h and POWERRPC SC and so on.

2, abnormal, this is a passive switch to the kernel state method, when the program in the user state execution, encountered an unknown exception, such as a missing fault.

3, external interrupt, is also a passive switch to the kernel state method, when the peripheral to complete the user requested operation will be issued an interrupt signal, the CPU will stop the current process scheduling, instead of processing the interrupt processing function defined by the operation. For example, hard disk reading or writing, or network IO, will also switch into the kernel state.

When the application process is created and started running, it is in the user state. Call the operating system to provide an interface (system call) to enter the kernel state (as above) when it is necessary to use disk, network read and write operations. And then return to the user state after execution, where the general application is not free to operate the kernel state data, has a certain protective effect.

Third, Intel's x86 architecture rating.

In fact, similar tiered tiering mechanisms have always been available, and the Intel x86 architecture uses 4 levels to indicate different privileged-level permissions. R0 is actually the kernel state, with the highest privileges. And the general application is in the R3 state-the user state. In Linux, there are also R1 and R2 two levels, which generally belong to the level of the driver. The Windows platform does not have R1 and R2 two levels, with only R0 kernel state and R3 User Configuration. On a permission constraint, a high privilege level state can be used to read data in a low-level state, such as a process context, code, data, and so on, but not otherwise. R0 can read r0-3 all the content, R1 can read r1-3, R2 and so on, R3 can only read their own data. Because the Shelllog should be written in the kernel.

Four, soft interrupt:

Prior to the work of one of the old owners of qiming often touch the concept of soft interrupt, also touch soft interrupt is int 80h, of course, this is relative to the external device hard interrupt. Today I finally understand that the so-called soft interrupt is the system called the entry instruction, int 80h.

Seriously there is a process execution to 0x80, the operating system will first protect the scene, in order to recover. The essence of this is the dump of stack information and register information. Then switch the privilege level into the kernel state, query 0x80 in the interrupt vector table, find the corresponding interrupt handler, and begin to perform interrupt processing. After processing, the iret needs to be cut back from the kernel state. In this process, the iret will eject from the kernel state the process contexts such as the previously saved registers, stack information, and so on, so that it can revert to the process environment that was processed before the outage and proceed with the original program schedule.

Linux kernel State, user profile, and INTELCPU privilege level--ring0-3