OSDev.org

• You don't appear to have a null descriptor, which is the one things that is unequivocally necessary for a valid GDT; or rather, you don't explicitly refer to it as such. While you do allocate the space for it, here,

  Code: Select all

  GDT:    dq 0

  the fact that it isn't labelled as such makes me think you don't understand why you are allocating that space. I am hoping I am wrong on this, but even if I am, not having an explicit Null entry is at the very least misleading, and poor coding practice (your coding standards are your choice, of course, but I would advise being explicit here).
• Every single one of the GDT descriptors has the same set of access settings, 10011010b. Let's break this down, for each of the values you have set, following the wiki page on the Global Descriptor Table and the Intel manuals (also, note that some of the names in the wiki differ from those in the manuals), with the bits numbered for the Access Byte (rather than for the descriptor as a whole):
  • Bit 7, P: 1 - Present flag. When set, as you have it in your descriptors, it means the segment is present in memory (both in the sense of there being physical memory for it, and that it is paged in).
  • Bits 6-5, DPL: 00 - Descriptor Privilege Level field, a pair of bits indicating the privilege level needed to access or execute the segment. Both bits cleared means that the segment has CR0 (kernel-only) access.
  • Bit 4, S: 1 - Segment type (system vs code/data). Set (as it is in this case), this indicates that the segment is either user code or user data. If it is cleared, then it is a system segment, and the Type field is ignored.
  • Bits 3-0. T: 1010 - the Type field. In the manuals, the next four flags because they are only used if the Segment Type flag is set. The wiki treats them as independent flags, which for most purposes is going to be more meaningful, IMAO.
    • Bit 3, X: 1 - Executable flag. 1 means it is a Code segment - values in the segment will be treated as executable instructions.
    • Bit 2, E/C: 0 - Expand/Conform (given as 'Direction/Conformance' in the wiki) flag union. This one is a union field, meaning it means different things depending on whether the segment is code or data. For a code segment, 1 means that the segment can be executed by processes with the same Privilege or lower level as the segment. Since that is Kernel in this case, it means that any process can execute it. For data, setting it to 1 means that the segment 'grows' down in memory; as a rule, only stack segments should be set to grow down.
    • Bit 1, R/W: 1 - Read/Write flag. As with DC, this is a union flag, with different interpretations for code and data segments. A 1 will mean read access for a code segment (but never write access; code segments are always read-only). For data segments (ones with the E bit cleared), it indicates both Read and Write access.
    • Bit 0, A: 0 - Accessed flag. This indicates that nothing has actually used the segment yet. As soon as that happened (either by executing code, reading data, or writing data), the flag gets set. This is mostly used when implementing virtual memory systems, IIUC.
  (IAN an expert on this, so C&CW.)
  So, what does all of this mean? It means all of the segments - including those you mean to be system or data - are listed as being "User Code, Present in memory, Readable but not writable, accessible only to kernel code, and not yet accessed." I am pretty sure that the at least some of the segments should be set differently, even though all of these overlap exactly.
• Similarly, let's take a look at the Segment Scaling Definition flags (called 'Flags' in the wiki), which are also all the set to the same values in your code (110xxxxx):
  • Bit 7, G: 1 - Granularity, which decides how the segment limits are scaled. Setting this to 1 indicates that you are using segment limits with a stride of 4 KiB (that is to say, a limit of 0x00001 would be a 4 KiB segment; a limit if 0x00004 would be a 16 KiB segment, etc.).
  • Bits 6, D/B: 1 - Default Argument Size/Big Segment flag. For code, when set (as it is here), this indicates that the default sizes for instruction operands and addresses are either 32-bit or 8-bit, while when cleared it means they are 16-bit or 8-bit. For data segments, it indicates whether it is a 64KiB maximum size segment, or a 4 GiB maximum size segment.
  • Bit 5, L: 0 - Long mode flag. Since it is cleared, it means you are in 32-bit protected mode, instead of 64-bit protected mode. When set, this further modifies the meanings of the G and D/B flags to indicate 64-bit values where it would have been 32-bit ones. The Intel manuals seem to indicate that this can in fact still be set even if the system as a whole is in 32-bit mode, but I am pretty sure things get weird if you do that... If anyone can add more on this, feel free.
  Since you are also setting all the segments to long strides, and all of them have a base of 0x00000000 and a limit of 0xFFFFF, this would mean that all of the segments are 4 GiB in total size, and all overlap each other exactly.

simeonz wrote:db 00100000b, should be db 00010000b or db 00000000b. You are setting the long mode flag for the TSS, but it needs to be always cleared (even for 64-bit TSS)

struc GDT_Entry
    .limit_0_15        resw 1
    .base_0_15         resw 1
    .base_16_23        resb 1
    .access            resb 1
    .flags_limit_16_19 resb 1
    .base_24_31        resb 1
endstruc

Pr_Shift equ 7
DPL_Shift equ 5
ST_Shift equ 4
Ex_Shift equ 3
DC_Shift equ 2
RW_Shift equ 1
Ac_Shift equ 0

G_Shift equ 7
DB_Shift equ 6
L_Shift equ 5

istruc GDT_Entry
    at .limit_0_15,        dw 0xFFFF
    at .base_0_15,         dw 0x0000
    at .base_16_23,        db 0x00
    at .access,            db (1 << Pr_Shift) & (0 << DPL_Shift) &  (1 << ST_Shift) & (1 << Ex-Shift) & (0 << DC_Shift) & (1 << RW_Shift) & (0 << Ac_Shift)
    at .flags_limit_16_19, db  0x0F & (1 << G_Shift) & (1 << DB_Shift) & (0 << L_Shift)
    at .base_24_31,        db 0x00
iend

%macro Make_GDT_Entry 0-10 0, 1, 1, 0, 1, 0, 1, 1, 0, 0x00000000, 0x00FFFFFF 
istruc GDT_Entry
    at .limit_0_15,        dw (%9 & 0x000FFFF)
    at .base_0_15,         dw (%10 & 0x0000FFFF)
    at .base_16_23,        db ((%9 & 0x00FF0000) >> 16)
    at .access,            db 0x80 & (%0 << DPL_Shift) &  (%1 << ST_Shift) & ((%2  & %0) << Ex-Shift) & ((%3 & %0)  << DC_Shift) & ((%4 & %0) << RW_Shift)  & ((%5  & %0) << Ac_Shift)
    at .flags_limit_16_19, db  ((%10 & 0x00FF0000) >> 16) & (%6 << G_Shift) & (%7 << DB_Shift) & (%8 << L_Shift)
    at .base_24_31,        db ((%9 & 0xFF000000) >> 24)
iend
%endmacro

GDT: 
NULL_Descriptor:   dq 0

        ; 32-bit code segment descriptor
Code32:
       Make_GDT_Entry

        ; 32-bit kernel segment descriptor
Kernel32:
    Make_GEDT_Entry 0

Schol-R-LEA wrote:I will add something that occurred to me earlier: the OP would do well to look at the macro and structure-definition features of their assembler (I am guessing it is NASM, but I am not sure) as a way of simplifying these declarations, both for avoiding repetition (by using the default initializations, if it allows them) and for making the setting process more meaningful by giving names to the fields and so forth.

simeonz wrote:

Schol-R-LEA wrote:I will add something that occurred to me earlier: the OP would do well to look at the macro and structure-definition features of their assembler (I am guessing it is NASM, but I am not sure) as a way of simplifying these declarations, both for avoiding repetition (by using the default initializations, if it allows them) and for making the setting process more meaningful by giving names to the fields and so forth.

True. I was thinking the same thing while counting the bit positions. The error may not have occurred, assuming this is the error, if the data was more "literate". Since I am not myself an avid assembler enthusiast, I am curious. Macros are somewhat less expressive then structures/records, so may we assume that the advice is to use NASM (for portability sake)? Or is using gas with a stronger preprocessor (like m4) a better option? Or NASM with m4? Or C/C++ with mostly inline assembler?

typedef struct
{
    uint16_t limit_0_15, base_0_15;
    uint8_t base_16_23;
    uint8_t access;
    uint8_t flags_limit_16_19;
    uint8_t base_24_31;
endstruc
}  __attribute__ ((aligned(8), packed )) GDT_Entry;

Schol-R-LEA wrote:I am pretty sure that a DPL of 00 across the board means those segments are all set to ring 0 only access.

simeonz wrote:

Schol-R-LEA wrote:I am pretty sure that a DPL of 00 across the board means those segments are all set to ring 0 only access.

I actually see a lot of DPL 3 segment descriptors. Also, your breakdown of the bits was correct, but if you go to Code643, the flags are 11111010b, which means present, DPL = 11b, etc. I am not sure what the 64-bit data segment descriptors are for, but may be unused.

Schol-R-LEA wrote:facepalm I could have sworn I had checked all of them and that they were all identical. .. that was careless of me.