Don't see any Protection fault After GDT set

[sharkwikios]

Attached is my boot.asm file that I am experimenting with.

I have made : limit as 0x000F , and at last in the code, after switching to the protected mode, I was referring the address 60000, and try to store few things there and do some calculations over that memory location, all such deeds are being allowed without giving segmentation/protection fault.

mov eax,[60000]
mov word [60000],500
mov eax, [60000]
add word [60000],200
mov eax, [60000]


May be i haven't understood the importance of GDT correctly. Can somebody throw light on is my expectation to get segmenation/protection fault is correct? if So, why am i not seeing that .

[Combuster]

I have made : limit as 0x000F

Nope. It's the 0xF000F that's bugging you

(F000F bug, oh the irony)

[sharkwikios]

I have made limit as 0x000F deliberately.

My expectation is if base is at 0x0000, and limit is 0x000F , then any memory reference( 6000 which is) outside [0x0000, 0x000F], should give a protection fault. But that is not happening.

I will try changing the value to 0xF000F and see, if this change can give a protection fault (but still i don't understand the reason why should it fault with this change - as memory address 60000 lies in base , base+limit range ).

[bluemoon]

I have made limit as 0x000F deliberately.

Code: Select all

DATASEL          EQU $-GDT  ; 4GB Flat Data at 0x0 with max 0xFFFFF limit
      DW     0x000F           ; Limit(2):0xFFFF
      DW     0x0              ; Base(3)
      DB     0x0              ; Base(2)
      DB     0x92             ; Type: present,ring0,data/stack,read/write (10010010)
      DB     0xCF             ; Limit(1):0xF | Flags:4Kb inc,32bit (11001111)
      DB     0x0              ; Base(1)

No, you don't. The limit is 000F000F x 4K (G bit is set).

[sharkwikios]

Finally, with few changes in the code., i am able see the protection fault.

(1) first of all, we should add "panic: action=ask" in bochs rc file
(2) The size of GDT has changed to 0x18 from 0x17. This is to accommodate the base of data segment as it is intended to be.

Thanks for bluemoon & Combuster for pointing out that 0x000F gets appended to the limit register. as it is indeed true.

But still didn't understood why was 0x000F getting appended before limit register. Need to investigate on that.
meanwhile if somebody can throw light why was this append happen, it would be great.

[Combuster]

Because it's explicitly set that way in your GDT. The limit field is spread over three bytes. Gotta fix 'em all.