Description of segments used in GDT

[dimakuv]

DISCLAIMER: THIS DESCRIPTION IS OLD, SOME FILENAMES ETC. MAY HAVE CHANGED!

I always forget about the magic numbers in the segment descriptors in GDT, so let me create a helper issue.

The GDT table contains a list of segment descriptors, each 8 bytes in size. The first descriptor is always a zero. Next typically come descriptors for the kernel code, kernel data, user code, user data, and then TSS. Here's a typical one, taken from vm-common/kernel_static_structs.S:

gdt_start:
    .quad   0
gdt_entry_kernel_cs:
    .long   0xffff, 0xaf9b00                    // 64-bit kernel code
    .long   0xffff, 0xaf9300                    // 64-bit kernel data
gdt_entry_user_cs:
    .long   0xffff, 0xcffb00                    // 32-bit user code
    .long   0xffff, 0xcff300                    // 32-bit user data
    .long   0xffff, 0xaffb00                    // 64-bit user code

Here is the image from Intel SDM on descriptors:

Here is the image of code/data encoding (when S = 1):

Now let's decipher some typical segment descriptors.

VM, bios/bios.S

0xffff, 0xcf9b00 = low 32 bits: 1111 1111 1111 1111 + high 32 bits: 1100 1111 1001 1011 0000 0000

• segment limit: the lower part is in low 16 bits: 1111 1111 1111 1111. The upper part is in bits 19..16 of high 32 bits: 1111. So the total segment limit is a 20-bit value: 0xFFFFF.
• segment base address: the lower part is in bits 31..16 of low 32 bits: all-zeros. The middle part is in bits 7..0 of high 32 bits: all-zeros. The upper part is in bits 31..24 of high 32 bits: all-zeros. So the total is a 32-bit value: 0x0 (start addressing from byte 0).
• Descriptor type (S): bit 12 in high 32 bits. Here 1 -- code or data descriptor.
• Descriptor privilege level (PDL): bits 14..13 in high 32 bits. Here 00 -- ring-0, used for kernel.
• Segment present (P): bit 15 in high 32 bits. Here 1 -- segment is present in memory (set). This bit is always set.
• Available for use by system software (AVL): bit 20 in high 32 bits. Here 0 -- who cares.
• 64-bit code segment (L): bit 21 in high 32 bits. Here 0 -- we are NOT in 64-bit mode (see D/B).
• Default operation size (D/B): bit 22 in high 32 bits. Here 1 -- 32-bit segment.
• Granularity (G): bit 23 in high 32 bits. Here 1 -- the segment limit is interpreted in 4KB units (NOT in bytes).
  • This G flag set allows to transform the 20-bit value in "segment limit" to a 32-bit value, thus covering all 32GB of addressable memory.
• Type: bits 11..8 in high 32 bits. Here 1011 -- code, X/R, accessed. The accessed bit is actually not interesting, could be zero.

Summary: this is a 32-bit code kernel segment descriptor, can be executed and read, covers address range 0..4GB.

0xffff, 0xcf9300 = low 32 bits: 1111 1111 1111 1111 + high 32 bits: 1100 1111 1001 0011 0000 0000

• segment limit: 0xFFFFF.
• segment base address: 0x0.
• S: 1 -- code or data descriptor.
• PDL: 00 -- ring-0, used for kernel.
• P: 1 -- present.
• AVL: 0 -- who cares.
• L: 0 -- we are NOT in 64-bit mode.
• D/B: 1 -- 32-bit segment.
• G: 1 -- limit in 4KB units.
• Type: 0011 -- data, R/W, accessed.

Summary: this is a 32-bit data kernel segment descriptor, can be read/written, covers address range 0..4GB.

VM, bootloader.S

0xffff, 0xaf9b00 = low 32 bits: 1111 1111 1111 1111 + high 32 bits: 1010 1111 1001 1011 0000 0000

• segment limit: 0xFFFFF.
• segment base address: 0x0.
• S: 1 -- code or data descriptor.
• PDL: 00 -- ring-0, used for kernel.
• P: 1 -- present.
• AVL: 0 -- who cares.
• L: 1 -- we are in 64-bit mode. (By the way, if L bit is set then D bit must be cleared.)
• D/B: 0 -- NOT 16/32-bit segment.
• G: 1 -- limit in 4KB units.
• Type: 1011 -- code, X/R, accessed.

Summary: this is a 64-bit code kernel segment descriptor, can be executed and read, covers address range 0..4GB.

NOTE: I think in 64-bit mode, segment base and limit are useless, but I didn't find a proof in Intel SDM.

0xffff, 0xcf9300 -- same as in data segment in BIOS (not that the data segment doesn't need to be 64-bit, since CPU only cares about the bitness of code).

0x0068, 0xcf8900 = low 32 bits: 0110 1000 + high 32 bits: 1100 1111 1000 1001 0000 0000

This is a TSS system segment, it has a special formatting:

• S: 0 -- system descriptor.
• Type: 1001 -- 64-bit TSS.
• For other parts see Figure 8-3 in Intel SDM, I don't want to go into those details.

VM Common, kernel_static_structs.S

0xffff, 0xaf9b00 = low 32 bits: 1111 1111 1111 1111 + high 32 bits: 1010 1111 1001 1011 0000 0000 -- same as in bootloader.

0xffff, 0xaf9300 = low 32 bits: 1111 1111 1111 1111 + high 32 bits: 1010 1111 1001 0011 0000 0000

• segment limit: 0xFFFFF.
• segment base address: 0x0.
• S: 1 -- code or data descriptor.
• PDL: 00 -- ring-0, used for kernel.
• P: 1 -- present.
• AVL: 0 -- who cares.
• L: 1 -- we are in 64-bit mode. (By the way, if L bit is set then D bit must be cleared.)
• D/B: 0 -- NOT 16/32-bit segment.
• G: 1 -- limit in 4KB units.
• Type: 0011 -- data, R/W, accessed.

Summary: this is a 64-bit data kernel segment descriptor, can be read/written, covers address range 0..4GB.

0xffff, 0xcffb00 -- low 32 bits: 1111 1111 1111 1111 + high 32 bits: 1100 1111 1111 1011 0000 0000

• segment limit: 0xFFFFF.
• segment base address: 0x0.
• S: 1 -- code or data descriptor.
• PDL: 11 -- ring-3, used for apps.
• P: 1 -- present.
• AVL: 0 -- who cares.
• L: 0 -- we are NOTE in 64-bit mode.
• D/B: 1 -- 32-bit segment.
• G: 1 -- limit in 4KB units.
• Type: 1011 -- code, X/R, accessed.

Summary: this is a 32-bit code userspace segment descriptor, can be executed and read, covers address range 0..4GB.

0xffff, 0xcff300 -- low 32 bits: 1111 1111 1111 1111 + high 32 bits: 1100 1111 1111 0011 0000 0000

• segment limit: 0xFFFFF.
• segment base address: 0x0.
• S: 1 -- code or data descriptor.
• PDL: 11 -- ring-3, used for apps.
• P: 1 -- present.
• AVL: 0 -- who cares.
• L: 0 -- we are NOTE in 64-bit mode.
• D/B: 1 -- 32-bit segment.
• G: 1 -- limit in 4KB units.
• Type: 0011 -- data, R/W, accessed.

Summary: this is a 32-bit data userspace segment descriptor, can be read/written, covers address range 0..4GB.

0xffff, 0xaffb00 -- low 32 bits: 1111 1111 1111 1111 + high 32 bits: 1010 1111 1111 1011 0000 0000

• segment limit: 0xFFFFF.
• segment base address: 0x0.
• S: 1 -- code or data descriptor.
• PDL: 11 -- ring-3, used for apps.
• P: 1 -- present.
• AVL: 0 -- who cares.
• L: 1 -- we are in 64-bit mode.
• D/B: 0 -- NOT 16/32-bit segment.
• G: 1 -- limit in 4KB units.
• Type: 1011 -- code, X/R, accessed.

Summary: this is a 64-bit code userspace segment descriptor, can be executed and read, covers address range 0..4GB.

[dimakuv]

I looked at these values again because I was analyzing the asm code here: https://wiki.osdev.org/Symmetric_Multiprocessing#AP_Initialization_Code

These are the GDT descriptors suggested in that code:

    .long 0x0000FFFF, 0x00CF9A00    ; flat code
    .long 0x0000FFFF, 0x008F9200    ; flat data
    .long 0x00000068, 0x00CF8900    ; tss

0x0000FFFF, 0x00CF9A00 -- low 32 bits: 1111 1111 1111 1111 + high 32 bits: 1100 1111 1001 1010 0000 0000

• segment limit: 0xFFFFF.
• segment base address: 0x0.
• S: 1 -- code or data descriptor.
• PDL: 00 -- ring-0, used for kernel.
• P: 1 -- present.
• AVL: 0 -- who cares.
• L: 0 -- we are NOTE in 64-bit mode.
• D/B: 1 -- 32-bit segment.
• G: 1 -- limit in 4KB units.
• Type: 1010 -- code, X/R, NOT accessed.

So the only difference from our descriptors is that it is NOT accessed, which I think totally irrelevant.

0x0000FFFF, 0x008F9200 -- low 32 bits: 1111 1111 1111 1111 + high 32 bits: 1000 1111 1001 0010 0000 0000

• segment limit: 0xFFFFF.
• segment base address: 0x0.
• S: 1 -- code or data descriptor.
• PDL: 00 -- ring-0, used for kernel.
• P: 1 -- present.
• AVL: 0 -- who cares.
• L: 0 -- we are NOTE in 64-bit mode.
• D/B: 0 -- 16-bit segment.
• G: 1 -- limit in 4KB units.
• Type: 0010 -- data, R/W, NOT accessed.

So the only differences from our descriptors are that it is NOT accessed and it is 16-bit.