{"componentChunkName":"component---src-templates-post-template-js","path":"/linux-memory-protect-gdt-ldt-en","result":{"data":{"markdownRemark":{"id":"c463abc8-2fe4-5c44-9b51-0d3df391def3","html":"
\n

This page has been machine-translated from the original page.

\n
\n

While reading UNIX source code, I became curious about the process of transitioning to protected mode during boot, so I’ve compiled my findings.

\n

I’ve tried to ensure technical accuracy, but if there are any errors, I would appreciate your feedback.

\n

This article targets Intel’s x86 CPU.

\n\n

Table of Contents

\n\n

Real Mode and Protected Mode

\n

Real Mode

\n

Real mode in x86 CPUs is an operating mode for Intel 8086 CPU compatibility.

\n

For x86, it is the initial operating mode at boot, and the BIOS also operates in real mode.

\n

Due to Intel 8086 CPU compatibility, real mode restricts all register address lengths to 16 bits.

\n

Reference: Real Mode - Wikipedia

\n

When referencing memory addresses, segment register values are used to access a 20-bit address space.

\n

Additionally, by enabling the A20 Line, a 21-bit address space can be used.

\n

Real mode does not have hardware-based memory protection or virtual memory, which exist in protected mode described later.

\n

Reference: Real Mode - OSDev Wiki

\n

Protected Mode

\n

Protected mode is an operating mode in x86 CPUs where the memory space is extended to 32 bits and memory and I/O protection becomes possible.

\n

Hierarchical privilege management (ring protection) and memory protection between tasks are possible.

\n

Reference: Protected Mode - Wikipedia

\n

Reference: Protected Mode - OSDev Wiki

\n

As mentioned earlier, since the BIOS operates in real mode on x86 CPUs, BIOS interrupts cannot be used after transitioning to protected mode.

\n

The mechanism of memory protection in protected mode is described later.

\n

Memory Protection in Protected Mode

\n

In protected mode, it is necessary to define the memory regions that a program can reference. This applies to kernel programs as well.

\n

First, x86 CPUs handle programs and data in units of contiguous memory regions called segments.

\n

Segment units come in two sizes: 64KB or 4GB.

\n

In memory protection in protected mode, the starting point and size of a memory region, as well as the read/write/execute permissions for that memory region, are called segment descriptors and are managed by descriptor tables.

\n

When a program references memory in protected mode, the DS register does not directly point to a memory address value.

\n

Instead, the DS register references the descriptor table to obtain segment information.

\n

This mechanism makes it essential to rewrite the descriptor table for a program to reference arbitrary memory regions.

\n

However, since the descriptor table cannot be rewritten by programs, as a result, programs cannot reference memory regions other than those predetermined, achieving memory protection.

\n

Reference: How Windows Works

\n

Reference: ASCII.jp: Understanding Windows Memory Management from x86 Mechanisms (1/4)

\n

About Descriptor Tables

\n

There are two types of descriptor tables: GDT (Global Descriptor Table) and LDT (Local Descriptor Table).

\n

GDT (Global Descriptor Table)

\n

The GDT is a descriptor table that is typically defined only once per system.

\n

The GDT manages multiple LDTs.

\n

x86 CPUs have a register called GDTR for pointing to the starting address of the GDT.

\n

Reference: Global Descriptor Table - Wikipedia

\n

Reference: Global Descriptor Table - OSDev Wiki

\n

LDT (Local Descriptor Table)

\n

LDTs are descriptor tables created for each program.

\n

In x86 CPUs, programs cannot access regions other than those defined in descriptor tables.

\n

Therefore, by having the OS manage non-conflicting descriptor tables for each program, it is possible to prevent each program from referencing other programs’ memory regions, achieving memory protection.

\n

Similar to GDTR, x86 CPUs have a register called LDTR for specifying the starting address of the currently used LDT.

\n

When a program tries to set a value in a segment register, the CPU references LDTR to obtain the address the program is trying to access and verifies access permission.

\n

Summary

\n

To organize the flow during program execution on x86 CPUs: first, when a program transitions to an execution state, the CPU identifies the index of the target program’s LDT from the GDT referenced via GDTR and stores it in LDTR.

\n

When a program requests a reference to a specific segment, the CPU references the LDT from LDTR to obtain the reference address and verify reference permission.

\n

Through this series of processes, programs cannot reference memory regions other than those predefined, achieving memory protection.

\n

References

\n","fields":{"slug":"/linux-memory-protect-gdt-ldt-en","tagSlugs":["/tag/linux-en/","/tag/os-en/","/tag/kernel-en/","/tag/english/"]},"frontmatter":{"date":"2022-01-09","description":"While reading UNIX source code, I became curious about the process of transitioning to protected mode during boot, so I've compiled my findings.","tags":["Linux (en)","OS (en)","Kernel (en)","English"],"title":"Notes on x86 CPU Memory Protection Mechanisms (GDT and LDT)","socialImage":{"publicURL":"/static/93ee63f2a992cec8ea2a833117345df4/linux-memory-protect-gdt-ldt.png"}}}},"pageContext":{"slug":"/linux-memory-protect-gdt-ldt-en"}},"staticQueryHashes":["251939775","401334301","825871152"]}