Segment Table

We've explored what segment table entries contain—base addresses, limits, protection bits. But there's a fundamental question we haven't fully addressed: Where are these segment tables stored, and how does the CPU find them?

This is a classic bootstrapping problem. The CPU needs segment descriptors to access memory, but those descriptors are themselves stored in memory. How does the hardware break this circular dependency?

The answer lies in special CPU registers that hold the physical addresses and sizes of descriptor tables. These registers—GDTR (Global Descriptor Table Register) and LDTR (Local Descriptor Table Register)—are the root of trust for segmented memory access. Everything flows from them.

Understanding descriptor table location is essential for operating system development. The OS must:

• Set up the GDT during boot
• Create per-process LDTs for isolation
• Switch LDTs during context switches
• Protect descriptor tables from user-mode modification

This page demystifies the architecture of descriptor table management.

x86 protected mode uses a two-tier descriptor table architecture:

1. Global Descriptor Table (GDT):

• System-wide, shared by all processes
• Contains descriptors for OS kernel, shared services
• Must always be present; CPU requires it
• Typically one GDT for the entire system (or per-CPU on SMP)

2. Local Descriptor Table (LDT):

• Per-process, unique to each process
• Contains descriptors specific to that process
• Optional; many processes don't use LDTs
• Provides additional isolation between processes

Why Two Tables?

The two-table design separates concerns:

• GDT: System segments that must be accessible regardless of which process is running (kernel code, kernel data, TSS, etc.)
• LDT: Process-specific segments that should differ between processes (user code, user data, user stack)

This design allows the OS to:

1. Keep kernel segments in GDT (always available)
2. Switch LDT on context switch (changes user segments)
3. Limit GDT modifications (security-critical, kernel-only)
4. Let processes have different segment layouts via different LDTs

The Global Descriptor Table Register (GDTR) is a special CPU register that holds the location and size of the GDT. It cannot be accessed like general-purpose registers—only special instructions can read or write it.

GDTR Structure:

┌────────────────────────────────────────────────────────┐
│ GDTR: 48 bits (10 bytes on 32-bit, 80 bits on 64-bit) │
├────────────────────────────────────────────────────────┤
│  Limit (16 bits)   │     Base Address (32/64 bits)    │
│  Bytes 0-1         │     Bytes 2-5 (or 2-9 on 64-bit) │
└────────────────────┴───────────────────────────────────┘

Limit: Size of GDT in bytes minus 1 (max 65535 = 8192 entries × 8 bytes)
Base:  Linear (virtual) address where GDT starts

Critical Points:

1. Base is Linear Address: With paging enabled, the GDT base is a virtual address that must be mapped in page tables.

2. Limit is Size-1: A limit of 0x17 means 24 bytes (3 entries × 8 bytes), not 0x17 entries.

3. Entry 0 is Null: GDT entry 0 is reserved as the "null descriptor" and cannot be used.

GDTR Instructions:

Security Consideration: SGDT Vulnerability

The SGDT instruction can be executed from user mode, revealing the GDT's location. This has been exploited for:

1. VM Detection: Hypervisors often relocate GDT, SGDT reveals this
2. ASLR Bypass: GDT location might leak kernel address space layout
3. Fingerprinting: Distinguish OS/hypervisor by GDT layout

Modern systems mitigate this:

• Hardware virtualization intercepts SGDT
• Some OSes randomize GDT location
• UMIP (User-Mode Instruction Prevention) blocks SGDT from Ring 3

The Local Descriptor Table Register (LDTR) points to the current process's LDT. Unlike GDTR which holds a direct memory address, LDTR holds a selector that references a descriptor in the GDT.

LDTR Structure:

┌──────────────────────────────────────────────────────────────────┐
│ LDTR: 16-bit visible selector + hidden descriptor cache         │
├──────────────────────────────────────────────────────────────────┤
│ Visible:  16-bit selector (index into GDT for LDT descriptor)  │
│ Hidden:   Cached LDT descriptor (base, limit, attributes)       │
└──────────────────────────────────────────────────────────────────┘

The Indirection:

1. LDTR contains a selector (e.g., 0x28)
2. This selector points to a descriptor in the GDT
3. That GDT descriptor is a system descriptor of type LDT
4. The LDT descriptor contains base/limit of the actual LDT
5. CPU caches this LDT information in LDTR's hidden portion

Why This Extra Level?

Having LDTR reference the GDT rather than directly containing a base/limit:

1. Consistency: All segment information flows through descriptors
2. Hardware Uniformity: Same caching mechanism for all segments
3. Protection: LDT descriptor in GDT has DPL, Present bit, etc.
4. Validation: CPU validates LDT descriptor when LDTR is loaded

LDTR Instructions:

• LLDT (Load LDT Register): Loads a selector into LDTR, CPU fetches and caches the LDT descriptor from GDT. Privileged (Ring 0).
• SLDT (Store LDT Register): Stores the LDTR selector to memory. Can be executed from user mode.

Null LDT:

If LDTR is loaded with a null selector (0), no LDT is active. Any segment selector with TI=1 (LDT indicator) will cause #GP because there's no LDT to look up. Many modern OSes run with LDTR=0.

Descriptor tables are arrays of 8-byte (or 16-byte in 64-bit mode for system descriptors) entries. Let's examine the structure and typical layouts.

GDT Structure:

Offset    Entry    Purpose
0x00      [0]      Null Descriptor (required, never used)
0x08      [1]      Kernel Code Segment (CS when in kernel)
0x10      [2]      Kernel Data Segment (DS/ES/SS when in kernel)
0x18      [3]      User Code Segment (CS when in user mode)
0x20      [4]      User Data Segment (DS/ES/SS when in user mode)
0x28      [5]      TSS Descriptor (for current CPU)
0x30      [6]      Per-CPU Data Segment (for FS/GS base)
          ...      Additional entries as needed

Typical Linux 32-bit GDT:

Selector to Entry Mapping:

The relationship between selectors and GDT entries:

Selector = (Index << 3) | TI | RPL

Index: Entry number in the table (0, 1, 2, ...)
TI:    Table Indicator (0 = GDT, 1 = LDT)
RPL:   Requested Privilege Level (0-3)

Examples:
  Selector 0x08 = (1 << 3) | 0 | 0 = Entry 1 in GDT, RPL=0
  Selector 0x1B = (3 << 3) | 0 | 3 = Entry 3 in GDT, RPL=3
  Selector 0x0F = (1 << 3) | 1 | 3 = Entry 1 in LDT, RPL=3

Finding a Descriptor:

segment_descriptor_t* find_descriptor(uint16_t selector) {
    uint16_t index = selector >> 3;
    bool use_ldt = (selector >> 2) & 1;
    
    if (use_ldt) {
        // TI = 1: Look in LDT
        if (ldtr_is_null())
            raise_gp(selector);  // No LDT loaded
        if (index >= ldt_limit / 8)
            raise_gp(selector);  // Index out of bounds
        return &ldt[index];
    } else {
        // TI = 0: Look in GDT
        if (index >= gdt_limit / 8)
            raise_gp(selector);  // Index out of bounds
        return &gdt[index];
    }
}

When a segment register is loaded with a selector, the CPU must find and validate the corresponding descriptor. This is a critical path that happens on every segment load.

Lookup Algorithm:

Physical Address Calculation:

GDT Entry Address = GDTR.Base + (Selector.Index × 8)

Example:
  GDTR.Base = 0xC0001000
  Selector = 0x18 (Index = 3)
  Entry Address = 0xC0001000 + (3 × 8) = 0xC0001018

Memory Access Pattern:

When loading a segment register, the CPU:

1. Reads 8 bytes from GDT/LDT (one cache line access usually)
2. Parses the descriptor
3. Caches result in segment register's hidden portion
4. Sets the accessed bit in the descriptor (another write)

The accessed bit write can cause TLB activity and cache coherence traffic on SMP systems.

When a computer boots, it starts in real mode (8086-compatible mode) with no GDT. Transitioning to protected mode requires setting up a GDT first. This is one of the first tasks of any OS bootloader or kernel.

Boot Sequence:

1. BIOS/UEFI loads bootloader in real mode
2. Bootloader sets up minimal GDT
3. Enable Protected Mode: Set PE bit in CR0
4. Far Jump: Load CS with protected mode selector
5. Load Data Segments: Set DS, ES, SS to protected mode selectors
6. Kernel may set up more complete GDT later

Minimal Boot GDT:

Why Far Jump After Setting CR0.PE?

When CR0.PE is set, the CPU is in protected mode, but CS still contains a real-mode value. The CPU continues in a weird hybrid state until CS is reloaded. The far jump:

1. Forces CS reload with a protected-mode selector
2. Flushes the instruction prefetch queue (contains real-mode decoded instructions)
3. Creates a clean entry into 32-bit protected mode

Kernel GDT Setup:

After basic boot, the kernel typically:

1. Relocates or rebuilds the GDT at a known virtual address
2. Adds more entries (TSS, user segments, per-CPU entries)
3. Reloads GDTR with the new GDT
4. Sets up per-CPU GDT copies for SMP

When using per-process LDTs, the operating system must manage LDT creation, population, and switching. Let's examine the complete lifecycle.

LDT Lifecycle:

1. Allocation: Kernel allocates memory for new process's LDT
2. Population: Fill LDT with process-specific segment descriptors
3. GDT Entry: Create LDT descriptor in GDT pointing to this LDT
4. Activation: Load LDTR during context switch to this process
5. Modification: Update LDT entries as process changes (new segments)
6. Deallocation: Free LDT memory when process exits

LDT Per-Process Architecture:

┌─────────────────────┐     ┌────────────────────────────────────┐
│  Global GDT         │     │  Process A's LDT                   │
├─────────────────────┤     ├────────────────────────────────────┤
│ [0] Null            │     │ [0] Null (reserved)                │
│ [1] Kernel Code     │     │ [1] User Code: Base=A's code area  │
│ [2] Kernel Data     │     │ [2] User Data: Base=A's data area  │
│ [3] User Code       │     │ [3] User Stack: Base=A's stack     │
│ [4] User Data       │     │ [4] User TLS: Thread-local storage │
│ [5] TSS             │     └────────────────────────────────────┘
│ [6] LDT for A ─────────────────────┘
│ [7] LDT for B ──────────────────────┐
│ ...                 │     ┌─────────────────────────────────────┐
└─────────────────────┘     │  Process B's LDT                    │
                            ├─────────────────────────────────────┤
                            │ [0] Null                            │
                            │ [1] User Code: Base=B's code area   │
                            │ [2] User Data: Base=B's data area   │
                            │ [3] User Stack: Base=B's stack      │
                            └─────────────────────────────────────┘

During a context switch, the operating system may need to switch LDTs and potentially update other segment-related state. This is a critical path that must be fast and correct.

Context Switch Segment Operations:

1. Save Current State: Save segment selectors to outgoing process's context
2. Switch LDT: Load new process's LDT selector into LDTR
3. Load Segment Registers: Load new process's segment selectors
4. Update FS/GS Bases: Set thread-local storage pointers

Context Switch Sequence:

Performance Considerations:

• LDT Switching: LLDT causes descriptor cache reload, but is fast if LDT descriptor is in cache
• Segment Register Loads: Each load validates the selector, costing a few cycles
• TLB Flush: Switching CR3 (page tables) flushes TLB—expensive but necessary for isolation
• FS/GS Base Updates: MSR writes are relatively expensive; cached in CPU for fast access

Optimization: Lazy LDT Switching:

If LDTs aren't used (null LDT), skip LLDT:

if (next_proc->ldt != NULL || prev_proc->ldt != NULL) {
    // Only switch if either process uses LDT
    lldt(next_proc->ldt ? next_proc->ldt->gdt_selector : 0);
}

Descriptor tables are security-critical. If an attacker could modify them, they could bypass all segment-based protection. The OS must ensure tables are protected.

Protection Mechanisms:

1. Ring 0 Modification Only:

• LGDT and LLDT are privileged—Ring 3 cannot change table locations
• GDT/LDT memory is in kernel space, inaccessible to user processes
• Even if user code knows the GDT address (via SGDT), it cannot write there

2. Page-Level Protection:

• GDT/LDT pages marked as supervisor-only (U/S bit = 0 in page tables)
• Even with flat segment model, paging prevents user access
• Pages should also be read-only for kernel (if OS supports it)

3. SMEP/SMAP (Modern x86):

• SMEP: Supervisor Mode Execution Prevention—kernel cannot execute user pages
• SMAP: Supervisor Mode Access Prevention—kernel cannot access user pages accidentally
• These prevent kernel bugs from being exploited to modify user-mapped GDT

4. Descriptor Validation:

• CPU validates descriptors on every segment load
• Invalid descriptors (wrong type, present=0) cause faults
• Self-protecting: even if attacker modifies a descriptor, the CPU checks it

Attack Scenario: GDT Corruption

Hypothetical attack without protections:

1. Attacker finds kernel vulnerability allowing arbitrary write
2. Writes to GDT, creating a code segment with DPL=3 and base=kernel
3. Loads this segment into CS (now running at Ring 3 with kernel access)
4. Reads/writes kernel memory freely

Mitigation:

• GDT in read-only kernel pages → write attempt page faults
• Or, if descriptor changed, CPU re-validates on segment load
• DPL=3 segment pointing to kernel memory still can't access Ring 0 data segments
• SMAP prevents even this if kernel has SMAP enabled

Read-Only GDT in Linux:

Linux marks GDT pages read-only and only remaps them writable briefly during modifications:

void update_gdt_entry(int index, ...) {
    set_page_rw(gdt_page);     // Temporarily make writable
    gdt[index] = new_entry;    // Modify
    set_page_ro(gdt_page);     // Restore read-only
}

We've comprehensively explored where segment tables live and how they're managed. Let's consolidate the key concepts:

Module Complete:

With this page, we've completed our deep dive into segment tables. You now understand:

• Segment Table Entry structure and all its fields
• Segment Base for addressing and relocation
• Segment Limit for bounds checking and protection
• Protection Bits for access control and privilege
• Segment Table Location for finding and managing tables

This comprehensive knowledge enables you to understand how operating systems implement memory protection at the segment level, which historically was (and partially still is) the foundation of protected-mode computing.