Using LLDT and setting up GDT for it

I am working on a small OS that will use a separate local descriptor table for each process. I understand that I will need to use the lldt to load the LDT segment from my GDT. I already have my kernel working in protected mode with a valid GDT, but I cannot figure out what the GDT record should look like for my LDT. I understand that its base address should point to my LDT, but I do not know what the privilege level and other attributes should be. Here is the NASM code that represents the LDT entry in my GDT:

 localTable equ $-gdt ; GDT entry #5 (selector 20h) dw 0x1FF ; limit to 64 descriptors dw 0x8000 ; base address db 0x0 db 0x89 ; probably incorrect... db 0x1f ; possibly incorrect... db 0x0 

If you are not familiar with NASM syntax, this table entry has a base address of 0x8000 and a limit of 511 (a total of 512 bytes or 64 entries). I read the section on GDT and LDT in the i486 programmer's reference manual, but I cannot completely understand how my GDT record should look.

Anyway, I load LDT like this:

 mov ax, 0x20 lldt ax 

This code causes the processor to generate a general security error (I process it interruptively). I would like to know two things:

1) Did I correctly describe my LDT in GDT? If not, what needs to be changed? 2) Can the lldt command fail because there is an invalid selector in my LDT itself? I read the specification of the LLDT instruction and it seems to me that it does not even read LDT memory, but I just want to be sure that LLDT does not fail, because I have a typo in my LDT data.

+6
source share
1 answer

Ok, I figured it out. The type I used ( 1001b ) was not what I needed. I found that type 2 ( 10b ) is used for LDT records. For recording, this information is provided in Chapter 6, Page 4 of the i486 Microprocessor Programming Guide. My functional GDT entry is as follows:

 localTable equ $-gdt ; GDT entry #5 (selector 20h) dw 0x1FF ; limit to 64 descriptors dw 0x8000 ; base address db 0x0 db 0x82 ; 10000010b (segment present set, WTM) db 0x1f db 0x0 
+3
source

Source: https://habr.com/ru/post/893964/


All Articles