Re: X86: Question about GDT loading

From: H. Peter Anvin

Date: Sun Aug 16 2026 - 17:13:24 EST


On 2026-08-16 13:45, Alexandre wrote:
> I was tracing the execution of the file "arch/x86/boot/compressed/head_32.S"
> with gdb when I noticed that the address used for the GDT in the GDTR
> structure pointed to the GDTR itself.
>
> This is weird because it would make the GDTR an entry in the GDT.
>
> I see that the code (line 64) loads address of the "gdt" label (line 172),
> which contains the GDTR data and the GDT entries, into eax and then stores
> that address, as the GDT offset field (line 65).
> Also, the GDT size field is calculated including the size of the GDTR data. (I
> unsure if that's intended)
>
> Taking a look with gdb and with the kernel compiled for i386, we can see that
> the address being used in the "lgdt" instruction  (line 66) is the same one
> being used as the offset for the GDT.
>
> gdb:
> 0x10001d        lgdtl  (%eax)
> (gdb) i r eax
> eax            0xca2000            13246464
> (gdb) x/64bx 0xca2000
> 0xca2000:       0x1f    0x00    0x00    0x20    0xca    0x00    0x00    0x00
> 0xca2008:       0x00    0x00    0x00    0x00    0x00    0x00    0x00    0x00
> 0xca2010:       0xff    0xff    0x00    0x00    0x00    0x9a    0xcf    0x00
> 0xca2018:       0xff    0xff    0x00    0x00    0x00    0x92    0xcf    0x00
> 0xca2020:       0x00    0x00    0x00    0x00    0x00    0x00    0x00    0x00
> 0xca2028:       0x00    0x00    0x00    0x00    0x05    0x00    0x00    0x00
> 0xca2030:       0x00    0x00    0x00    0x00    0x00    0x00    0x00    0x00
> 0xca2038:       0x00    0x00    0x00    0x00    0x00    0x00    0x00    0x00
> (gdb)
>
> After the size field ( 0x1f 0x00 ) the address of the GDT points to the GDTR
> ( 0x00 0x20 0xca 0x00 ).
>
> Please let me know if that is intended or not.
>
It is intended. Slot 0 in the GDT is not used, so it is a pretty common
convention to stuff the pointer to the GDT itself into that slot.

For 32 bits that is perfectly safe. On 64 bits, it ends up taking up slot 1 as
well; this is *not* safe for a kernel address as it would be interpreted as a
user-space code descriptor for a single-byte code segment somewhere in the low
16 MB of memory, addressable as 0x13:0. This could be used to derive bits
[55:32] of the kernel GDT base from user space.

Therefore this must NOT be done in 64-bit mode.

-hpa