Re: X86: Question about GDT loading
"H. Peter Anvin" <[email protected]>
| Newsgroups | gmane.linux.kernel |
|---|---|
| Message-ID | <[email protected]> |
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