Re: X86: Question about GDT loading

Re: X86: Question about GDT loading

[H. Peter Anvin]

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

Re: X86: Question about GDT loading

[H. Peter Anvin]

On 2026-08-16 14:12, H. Peter Anvin wrote:
> 
> 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.

Corrected: addressable as 0xb:0.

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

Formally speaking: long mode.

	-hpa

Re: X86: Question about GDT loading

[Christian Ludloff]

>> 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.
>
> Corrected: addressable as 0xb:0.
>
>> Therefore this must NOT be done in 64-bit mode.
>
> Formally speaking: long mode.

A mixed-mode GDT can safely place a task gate descriptor
at GDT offset 8 though, because the first two bytes of it are
reserved/ignored (in legacy mode) and because task gates
are no longer used/supported (in long mode).

    https://www.sandpile.org/x86/desc.htm

So the technique still works... if GDTR base [63:32] is zero;
else two copies of the GDT end up being used (assuming a
LGDT in legacy mode, then a mode switch, then a LGDT in
long mode again [to load the upper base bits]).

The technique itself does go back at least to the early '90s:

    https://www.rcollins.org/Productivity/NullDescriptor.html

--
C.

Re: X86: Question about GDT loading

[Brian Gerst]

On Sun, Aug 16, 2026 at 4:58 PM Alexandre <alexramos25.pt@gmail.com> 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.

The first slot of the GDT is unused, as it corresponds to the null
selector.  So it's a common trick to use that space for the GDT
descriptor, at least on 32-bit.  There isn't enough space for a 64-bit
base address.

X86: Question about GDT loading

[Alexandre]

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:
Assembly:
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.

Kind regards,
Alexandre Ramos