Consistent code segment, inconsistent code segment

Consistent code segment, inconsistent code segment
Conforming code segment

[Reprinted] -- the source is unknown, because people also say "reprinted"

 

The reason for this definition is that the system needs to be secure: the kernel must be separated from the user program. The kernel must be secure and cannot be interfered by the user program.
But sometimes user programs also need to read some data from the kernel. What should I do?
As a result, the OS opens up some segments that can be accessed by user programs, but does not allow user programs to write data.
1. the kernel does not need to know the data of the user program. The kernel does not need to call the data of the user program. The kernel does not need to be transferred to the user program.
2. the user program can only access some shared segments in the kernel. We call these segments as consistent segments.
3. the user program cannot access the segment not shared by the kernel.

1. Data and code in x86 are stored in segments: [section]
2 ...... the program moves back and forth between segments by selecting sub-/Door calls and so on.
3. Each Selection Sub-/door call sub-selection is graded: This is in the selection character structure: RPL (the last two digits)
4: each code segment/data segment is also hierarchical. This is in the gdt descriptor.
The caller's selector and called segment are all divided into different levels. Where are these levels used? Used in consistent code segments, that is, shared segments.

Since it is shared, there are rules:
For consistent code segments: Shared segments.
1. Applications with high privileges are not allowed to access low-privileged data: core states are not allowed to call user-state data.
2. Applications with low privilege level can access data with high privilege level, but the privilege level does not change: user mode or user mode.
For common code segments, this is also a non-consistent code segment:
0. Only access from the same level is allowed.
1. Access to different levels is absolutely prohibited: the Core mode does not use the user mode, and the user mode does not use the core mode.

Summary: It seems that these things are different from what our beginners expected. The core State is the boss. Anyone who wants to access them is allowed. In fact, it is wrong. The result is exactly the opposite.
This is because it prevents the user from tampering with the data in the core State, causing the core State to execute the user code, and causing the kernel to crash.
The kernel is broken. Everything may happen.

 

Notes: Pay attention to the issues of privilege level and privilege level.
Privileged level
0 system level: privileged level, high privilege level, low
3. user level: privileged level, low privilege level, and high level