8. Linux kernel-memory addressing-segment mechanism (2)

In this section, we will discuss how Linux uses the segment mechanism in the x86 structure, and specifically how to bypass the segment mechanism in Linux.

We decided to start from Linux's portability. We say that Linux is a widely transplanted operating system that supports x86, Alpha, arm, and other architectures. However, many structures do not support the segment mechanism, such as arm and Alpha, but they all support the paging mechanism. Linux has done a lot of work in order to port it to x86.

First, we should say that x86 must have a segment mechanism, so we need to run it on x86.ProgramThe segment mechanism is inevitable. So we thought of a segment descriptor that we previously thought of, in bytes or pages, represents an attribute bit of segment length. We said that when G = 1, the unit is page (4 kb), so the maximum length of a segment can be 4 GB. Based on this, we set the base address of a segment to 0, and then let G = 1, so the maximum length of a segment is 4 GB, this clearly maps to our 4 GB linear address space. Through such processing, we can say that the block mechanism of X86 has been virtualized, and logical addresses and linear addresses can be confused.

However, x86 also stipulates thatCodeSegment and Data Segment create different segments, so Linux creates a segment descriptor with a base address of 0 and a segment length of 4 GB for the code segment and data segment respectively. In addition, because the Linux kernel runs at the privileged level 0 and the user program runs at the privileged level 3, x86 stipulates that a user program with the privileged level 3 cannot access the kernel code with the privileged level 0, therefore, Linux creates code segments and data segments for the kernel and user programs respectively.

Therefore, in arch/x86/include/ASM/segment. H, four segments are defined as follows (that is, the values in the registers during machine startup ):

 
# DEFINE _ kernel_cs (gdt_entry_kernel_cs * 8) # DEFINE _ kernel_ds (gdt_entry_kernel_ds * 8) # DEFINE _ user_ds (gdt_entry_default_user_ds * 8 + 3) # DEFINE _ user_cs (gdt_entry_default_user_cs * 8 + 3)
 

Where:

 
# Define limit 14 # define limit 15 # define gdt_entry_kernel_base (12) # define gdt_entry_kernel_cs (gdt_entry_kernel_base + 0) # define aggregate (gdt_entry_kernel_base + 1)
 

 

The result of the above definition is as follows:

# DEFINE _ kernel_cs 0x00c0/* kernel code segment, Index = 12, Ti = 0, RPL = 0 */# DEFINE _ kernel_ds 0x00d0/* kernel code segment, Index = 13, ti = 0, RPL = 0 */# DEFINE _ user_ds 0x00e3/* User code segment, Index = 14, Ti = 0, RPL = 3 */# DEFINE _ user_cs 0x00f3/* User code segment, Index = 15, Ti = 0, RPL = 3 */
 

 

So we can use the four indexes, to find the segment descriptor corresponding to the four segments, and we declare the privilege of the kernel code segment as 0 and the privilege of the user code segment as 3, if Ti is 0, we always access the Global Descriptor Table.

In our corresponding segment descriptor, we set g to 1 and the segment upper limit to 0 xfffff, which cleverly bypasses the x86 segment mechanism.

However, one problem that I cannot ignore here is that we set the upper limit of all four segments to 4 GB, which completely damages the protection of segments. That is to say, we may have simply modified the data of other segments. Fortunately, we still have a linear address. Fortunately, we haven't loaded the data into the memory yet. Therefore, we have a solution to this problem. This is the paging mechanism to be discussed below.