For a 32-bit operating system, its addressing space (also called virtual address space or linear address space) size is 4G (that is, 2 to the 32nd power). This means that a process can have a maximum address space of 4G.
The core of the operating system is the kernel, which is separated from ordinary applications and has permission to access protected memory space and underlying hardware devices. In order to ensure the security of the kernel, modern operating systems usually restrict user processes from directly operating the kernel.
Typically, this is achieved by dividing the virtual address space into two parts, kernel space and user space. As far as the Linux operating system is concerned, the highest 1G bytes (from virtual address 0xC0000000 to 0xFFFFFFFF) are used by the kernel and are called kernel space. The lower 3G bytes (from virtual address 0x00000000 to 0xBFFFFFFF) are used by individual processes and are called user space.
In other words, among the 4G address space of each process, the highest 1G is the same, that is, the kernel space. Only the remaining 3G is the available space for the process itself.
It can be understood like this: "The maximum 1G kernel space is shared among all processes!" The following figure shows the allocation of 4G address space for each process (picture comes from the Internet):
Among all the instructions of the CPU, some are very dangerous and will cause the system to crash if used incorrectly, such as clearing memory, setting the clock, etc. If all programs are allowed to use these instructions, the probability of a system crash will be greatly increased.
So, the CPU divides instructions into privileged instructions and non-privileged instructions. For those dangerous instructions, only the operating system and its related modules are allowed to use them, and ordinary applications can only use those instructions that will not cause disaster.
For example, Intel's CPU divides the privilege level into 4 levels: Ring0~Ring3. In fact, Linux systems only use two run levels, Ring0 and Ring3 (the same is true for Windows systems).
When a process is running at Ring3 level, it is said to be running in user mode, and when it is running at Ring0 level, it is said to be running in kernel mode.
Okay, now we need to explain what kernel mode and user mode are: "When a process runs in kernel space, it is in kernel mode, and when a process runs in user space, it is in user mode."
In kernel mode, the process runs in the kernel address space, and the CPU can execute any instructions at this time. The running code is not subject to any restrictions and can freely access any valid address or directly access the port.
In user mode, the process runs in the user address space. The executed code is subject to many checks by the CPU. They can only access pages that are accessible in user mode as specified in the page table entries mapping their address space. Virtual address, and can only directly access the accessible ports specified in the I/O Permission Bitmap in the Task Status Segment (TSS).
For the previous DOS operating system, there was no concept of kernel space, user space, kernel mode, and user mode. It can be considered that all code runs in the kernel mode, so user-written application code can easily crash the operating system.
For Linux, the design of distinguishing kernel space and user space isolates operating system code (operating system code is much more robust than application code) and application code.
Even if an error occurs in a single application, it will not affect the stability of the operating system, so that other programs can still run normally (Linux is a multi-tasking system!).
"So, distinguishing between kernel space and user space is essentially to improve the stability and availability of the operating system."
In fact, all system resource management is completed in the kernel space. For example, reading and writing disk files, allocating and recycling memory, reading and writing data from network interfaces, etc.
Our application cannot directly perform such operations. But we can accomplish such tasks through the interface provided by the kernel.
For example, if an application wants to read a file on the disk, it can initiate a "system call" to the kernel and tell the kernel: "I want to read a certain file on the disk."
In fact, a special instruction is used to allow the process to enter the kernel state (to the kernel space) from the user state. In the kernel space, the CPU can execute any instructions, including reading data from the disk. The specific process is to first read the data into the kernel space, then copy the data to the user space and switch from the kernel mode to the user mode.
At this point, the application has returned from the system call and obtained the desired data, and can happily continue execution. To put it simply, the application outsources high-tech things (reading files from disk) to the system kernel, and the system kernel does these things professionally and efficiently.
For a process, the process of entering kernel space from user space and finally returning to user space is very complicated. For example, the concept "stack" that we often come into contact with actually has a stack in the kernel mode and user mode.
When running in user space, the process uses the stack in user space, and when running in kernel space, the process uses the stack in kernel space. Therefore, each process in Linux has two stacks, one for user mode and one for kernel mode.
The following figure briefly describes the conversion between user mode and kernel mode:
Since the user mode process must switch to the kernel mode in order to use the system resources, let's take a look at how many ways the process can enter from the user mode to the kernel mode.
In summary, there are three ways: system call, software interrupt and hardware interrupt. Each of these three methods involves a lot of operating system knowledge, so they will not be expanded upon here.
Next, let’s take a look at the structure of the entire Linux system from the perspective of kernel space and user space. It can be roughly divided into three parts, from bottom to top: hardware -> kernel space -> user space. As shown in the picture below (this picture comes from the Internet):
On top of the hardware, the code in the kernel space controls the use of hardware resources. The code in the user space can only use the hardware resources in the system through the system call interface (System Call Interface) exposed by the kernel. . In fact, not only Linux, but also the design of Windows operating systems is similar.
In fact we can summarize the activity of each processor at any given point in time as one of the following three:
The above three points include almost all situations. For example, when the CPU is idle, the kernel runs an empty process, which is in the process context but runs in the kernel space.
Note: The interrupt service routines of Linux systems are not executed in the context of the process. They are executed in a specialized interrupt context that is independent of all processes.
The reason why there is a special execution environment is to ensure that the interrupt service program can respond to and handle the interrupt request as soon as possible, and then exit quickly.
Большинство современных операционных систем защищают безопасность и стабильность самой операционной системы за счет проектирования пространства ядра и пользовательского пространства. Поэтому, когда мы читаем информацию об операционных системах, мы часто сталкиваемся с такими понятиями, как пространство ядра, пространство пользователя, режим ядра и режим пользователя.Я надеюсь, что эта статья поможет вам понять эти основные понятия.
The above is the detailed content of What are Linux kernel space and user space?. For more information, please follow other related articles on the PHP Chinese website!
![[Web front-end] Node.js quick start](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
