[SOLVED]Ring3 Prob: Int XX, Solar's malloc & Durand printf

[Muneer]

Hi,

I have been trying to switch to ring 3. I can switch to it but I cannot execute Durand's port of printf or Solar's malloc from ring 3. From ring 0 both works fine . But I can execute my own version of puts(which hooks to Durand's printf). When the above are executed from ring 3, the qemu "info registers" displays cs and ss as changed to ring 0 descriptors after GPF and all other segment registers as Ring 3 data descriptors i,e no change occurs .
The Page Directory and Page Table of the whole kernel has been marked user/rw/present just for testing purposes. Also I cannot switch back to ring 0 by "int 0" with jmp $ inside IRQ0_ISR_Handler but instead a GPF occurs placing cs and ss in ring 0 and all else in ring 3.


Asm Code
---------------

Code: Select all

            Mov Eax , TASK_STATE_SEGMENT
            Mov [First] , Al
            Mov [Second] , Ah
            Shr Eax , 16
            Mov [Third] , Al
            Mov [Last] , Ah
            Lgdt   [GDTR]
            Jmp dword 8: ReLoad_Protected ; Reloading GDTR
ReLoad_Protected :
            Mov   Ax , 0x10      ;  Data Segment Initialize
            Mov   Ds , Ax
            Mov   Es , Ax
            Mov   Fs , Ax
            Mov   Gs , Ax
            Mov   Ss , Ax       ;  Stack Segment
            Mov Ax , 0x2B      ; TSS Descriptor
            Ltr Ax            ; Load TSS

Call   Main ; Call C routines

Hang: Hlt
   Jmp   Hang



; GDT WITH TSS SUPPORT
GDTR :

      dw   GDT_End - GDT - 1         ;   16 Bit Size Limit Of GDT
                dd   GDT                  ;   32 Bit Linear Address Of GDT

GDT :
      dd   0x00000000 ,   0x00000000      ;   Null
           dd   0x0000FFFF ,   0x00CF9A00      ;   Kernel Code
                dd   0x0000FFFF ,   0x00CF9200      ;   Kernel Data
                dd   0x0000FFFF ,   0x00CFFA00      ;   User Code
                dd   0x0000FFFF ,   0x00CFF200      ;   User Data
TSS:
         db 103
              db 0
First:                db 0
Second:            db 0
Third:           db 0
         db 233
         db 0
Last:                 db 0

   

GDT_End :

C Code
-----------

Code: Select all

void TSS_init(void){

   memset_byte(&TASK_STATE_SEGMENT,sizeof(TSS),0); // Clearing the TSS structure
   TSS = &TASK_STATE_SEGMENT;
   TSS->cs = 0x0B;
   TSS->ds = TSS->es = TSS->fs = TSS->gs = TSS->ss = 0x13;
   TSS->ss0 = 0x10;
   TSS->esp0 = 0xC03FF000;
        TSS->iomap_base = ( unsigned short ) sizeof(TSS);  // set to point beyond the TSS limit
   switch_to_user_mode();
}


void switch_to_user_mode()
{
    // James's Code to switch to user mode
   // Set up a stack structure for switching to user mode.
   asm volatile("  \
     cli; \
     mov $0x23, %ax; \
     mov %ax, %ds; \
     mov %ax, %es; \
     mov %ax, %fs; \
     mov %ax, %gs; \
                   \
     mov %esp, %eax; \
     pushl $0x23; \
     pushl %eax; \
     pushf; \
     pushl $0x1B; \
     push $1f; \
     iret; \
   1:");

        puts("Blah-blah");     // No GPF. Status OK. All in Ring 3
        //printf ("%d",65);     // GPF. Status: Cs in RING 0. SS in Ring 0
   //malloc(5);             // GPF. Status: Cs in RING 0. SS in Ring 0

a: goto a; // Tempororily Stopping for debugging purposes
} 

Compiler: GCC Cross Compiler i586-elf
Virtual Machine: qemu
develpment machine: x86. OS: lubuntu 11.04

[Combuster]

A ring switch will always load CS and SS with ring 0 values, so that is obviously correct behaviour.

Since it's an GPF you will have the error code as well as the faulting CS:IP:FLAGS:SS:SP; those are more important diagnostics since you can use that to actually determine the exact cause of the GPF and test your assumptions against them. Knowing the exact instruction raising the GPF would be welcome too.

In the typical flat model, GPFs will not be possible in compiled C code, which means that the bug should be searched in anything setting up userland code.

[rdos]

You cannot directly call ring 0 functions from ring 3. That is part of the reason why the are different rings. In order to use ring 0 functions from ring 3, there is a need to setup call gates.

[Muneer]

A ring switch will always load CS and SS with ring 0 values, so that is obviously correct behaviour.

That is ok if I try to ring switch from 3 to 0 using int 0 .
But why does it happen when I call malloc or printf.

Since it's an GPF you will have the error code

The Error code is 0 and that doesnt advance us further. A GPF with error code of 0 doesnt say the cause.

as well as the faulting CS:IP:FLAGS:SS:SP;

How to get that in qemu. Cant get it from "info registers".

You cannot directly call ring 0 functions from ring 3. That is part of the reason why the are different rings. In order to use ring 0 functions from ring 3, there is a need to setup call gates.You cannot directly call ring 0 functions from ring 3. That is part of the reason why the are different rings. In order to use ring 0 functions from ring 3, there is a need to setup call gates.

How can the processor tell the difference of a compiled c code running in ring 0 or ring 3 if the page level protection mechanisms are made user/rw/present for all the KernelSpace in the PD and PT.

[Combuster]

as well as the faulting CS:IP:FLAGS:SS:SP;

How to get that in qemu. Cant get it from "info registers".

Then how on earth did you get the error code?

[Solar]

A ring switch will always load CS and SS with ring 0 values, so that is obviously correct behaviour.

That is ok if I try to ring switch from 3 to 0 using int 0 .
But why does it happen when I call malloc or printf.

My malloc() placeholder (and, I would imagine, any implementation of malloc()) includes system calls. In my case, _PDCLIB_allocpages(), which in the example implementation calls brk() and sbrk().

As for why a printf() might croak, I don't know. The implementation in PDCLib shouldn't do any system calls. I know that some printf() implementations out there do malloc() calls; mine doesn't.

These system calls don't work as-is from ring 3.

[Muneer]

Then how on earth did you get the error code?

I got the error code from my GPF_Handler. pop eax.........etc.

y malloc() placeholder (and, I would imagine, any implementation of malloc()) includes system calls. In my case, _PDCLIB_allocpages(), which in the example implementation calls brk() and sbrk().

I had hooked your _PDCLIB_allocpages() to my k_map.

These system calls don't work as-is from ring 3.

Why?

[Muneer]

I managed to get solution to the first problem.
The reason I couldnt try int 0 etc.. was because my IDT descriptor's DPL was 0. Once I changed it to 3
I could easily get to ring 0 from ring 3 and back.. I have now setup an IDT desriptor for System Calls.
This spawns a new question (ignore if it is off-topic but seems a nice time to ask)
1) Should System Call's IDT descriptor be a trap Gate or an interrupt gate (I know it is matter of design but still which would be best) . The difference being disabling interrupts.


printf and malloc still breaks. Havent figured that yet.
could anyone point any solution to this

[Muneer]

status of printf and malloc

Starting kernel:
In Ring 0
works
switches to Ring 3
GPF
switches back to Ring 0
works


any clues?

[Solar]

These system calls don't work as-is from ring 3.

Why?

Take a step back. Take PDCLib out of the equation. Ask yourself: Could your ring3 code call k_map()?

[Muneer]

Take a step back. Take PDCLib out of the equation. Ask yourself: Could your ring3 code call k_map()?

Of course it can since I have marked all my kernel pages as user/rw/present (for testing purposes) and uses a recursive page directory technique to map the pages. I dont see the use of any privileged instructions here since all it takes to implement is mere memory accesses.
I dont see any difference between ring3 and ring0 code other than the privileged instruction in this picture. Or do I miss something?

[gerryg400]

You cannot write to cr3 in ring3. So you cannot flush the TLB from ring 3.

[Combuster]

Then how on earth did you get the error code?

I got the error code from my GPF_Handler. pop eax.........etc.

Meep. Zero points for the incomplete answer.

That ( included) was a hint. How does the error code go from the processor to your code, and why can you only get the error code and not everything else the processor stores on an exception? I sure do hope you didn't copy code you did not understand.

[Muneer]

You cannot write to cr3 in ring3. So you cannot flush the TLB from ring 3.

A big Thanks. How could I have overlooked that. So that explains the reason for malloc's GPF from ring 3 for it hooks around my k_map() which calls the invalidate_page. Was that what Solar was saying, If so, sorry for not taking that as it is. So malloc GPF's because of privileged instruction.

That leaves me with only Durand's printf GPF'ing in ring 3. Must check out for a privileged instruction in function that hooks around my printf. But I do doubt it.

That ( included) was a hint. How does the error code go from the processor to your code, and why can you only get the error code and not everything else the processor stores on an exception?

Isnt it because the processor was designed so. Is there anything that the processor stores other than the error code on an exception. Or am I missing something. I really am no good at deciphering hints.

I sure do hope you didn't copy code you did not understand.

Give me 1 reason for that suspicion.
My first post here on osdev was about a code that worked but should not have worked because it doesnt sit well with the theory.
Everything I have written in my I code, I have written. Wont copy code without understanding it. Although I must admit I havent understood or rather looked what Solar's or Durand's code do behind the scenes. I know from Solar stating that his "free" wont return pages to the OS.

[gerryg400]

It seems that you have solved 2 problems in your code and there is one more to solve ?

What does "hooks to" mean in this context ?

I can execute my own version of puts(which hooks to Durand's printf).

Where can I find Durand's printf ?