From Real Mode to Protected Mode — Building Custom GDT & IDT for x86 Security

Field notes on the transition every x86 system makes during boot — from 16-bit real mode to 32-bit protected mode — and what the GDT and IDT actually are. Every OS does this in the first second of life. Almost no engineer can tell you what those tables really define.

Status: Companion blog draft for the existing video. Long-form transcript + bridge framing TBD.

Companion assets

• Original video:

  From Real Mode to Protected Mode: Building Custom GDT & IDT for x86 Security

• GitHub: harrison001/NanoBoot — minimal bootloader framework with protected-mode setup, GDT/IDT handling, custom interrupts, simple preemptive scheduler (<5KB total)

TL;DR

Every x86 machine boots in real mode — 16-bit segmented addressing, no memory protection, BIOS-shaped. The transition to protected mode is not “flip a bit.” It requires defining a Global Descriptor Table (GDT) for memory segmentation, an Interrupt Descriptor Table (IDT) for handling traps and interrupts, and then executing a far jump that flushes the CPU pipeline and enables protected-mode addressing. Understanding what’s in those tables is understanding what “user space vs kernel space” actually means at the hardware level.

The setup

• Hand-written x86 assembly: real-mode bootloader → defines GDT → loads it → flips CR0 bit 0 → far jumps into protected-mode code
• QEMU + GDB
• Custom IDT entries to catch your own interrupts

Debug command transcript

# TODO: paste actual assembly + gdb sequence from the video
# ; in boot assembly:
# lgdt [gdt_descriptor]
# mov eax, cr0
# or eax, 1
# mov cr0, eax
# jmp 0x08:protected_mode_entry
#
# (gdb) target remote :1234
# (gdb) info registers cr0
# (gdb) ni  # step through the transition
# (gdb) info registers cs

What’s actually happening

GDT (Global Descriptor Table): A list of memory segment descriptors. Each descriptor defines a base address, a limit, a privilege level (ring 0–3), and access flags. The CPU uses GDT entries to interpret what CS, DS, SS, etc. mean.

IDT (Interrupt Descriptor Table): A list of gate descriptors — one per interrupt/exception vector. Each gate points to a handler routine and specifies what privilege level can trigger it. When a page fault happens, the CPU looks up vector 14 in the IDT and jumps to whatever handler is registered there.

The transition: Real mode → protected mode happens in one far jump after CR0.PE is set. Before the jump, your CPU interprets memory addresses as segment:offset with 20-bit addressing. After the jump, it uses GDT-defined descriptors with 32-bit linear addressing and ring-level enforcement.

What this teaches backend / AI infra engineers

You’ll never write a bootloader at work. But you operate every day inside the world the bootloader created:

• Ring 0 vs ring 3 is the foundation of “user space cannot directly do hardware I/O.” Every syscall is a controlled transition from ring 3 to ring 0, governed by IDT entries.
• Memory protection between processes is built on the same segmentation/paging machinery that the GDT bootstraps.
• Privilege escalation vulnerabilities ultimately abuse mistakes in interrupt or descriptor handling. Knowing what an IDT gate’s privilege level is means understanding what a kernel exploit is doing.

For AI infra: every GPU driver entry point and every syscall in your inference path is governed by these tables. The “kernel boundary” you pay overhead crossing is not abstract — it’s a CPU instruction sequence that loads new segment selectors via the GDT.

Related work

• Video: Debugging Real-Mode Bootloader in GDB — the step before this one
• Video: Bootloader from Scratch — the broader bootloader walkthrough
• GitHub: NanoBoot

I occasionally advise small teams on backend reliability, Go performance, and production AI systems. Learn more: /services