Ring3 Tasks GPF on IRET

pcmattman · Post by **pcmattman** » Sat Jul 21, 2007 1:13 am

Currently I am in the process of switching all usermode processes to ring3 instead of ring0, but it's not working out too well...

If I use ring3, whenever an interrupt fires I get a GPF from the 'iret' line (at the very end of it). As soon as I switch all usermode tasks back to ring0, I have no problems at all.

This is really confusing, but I've worked at it and have found that on the GPF the error code shows that the faulting segment was 0x18, my ring3 code segment.

Any ideas? I've been reading the Intel Manuals and so far nothing has worked.

Edit: Another thing, when I OR all segment descriptors by 3, I get a page fault for an invalid privilege level access (these pages are not supervisor pages).

XCHG · Post by **XCHG** » Sat Jul 21, 2007 2:12 am

pcmattman,

I had the same problem when I was implementing my scheduler and later I found out that the RPL of my user processes' CS/DS/ES/FS/GS and etc were not set to 3. Make sure the RPL of the segment selectors that you create for your user processes is set to 3. The RPL is the rightmost 2 bits of a segment selector.

You say that the reported error indicates that the code segment that has caused the GPF is 0x18 that is equal to 24 in decimal. 24 is divisible by 8 and thus it shows that you have not set the rightmost 2 bits of the CS of the process to 1 (all the bits). So the segment selector of 0x18 will become 0x1B after it is changed to RPL3 (0x1B 11011; note that the rightmost 2 bits are set to 1). Basically for every user process, make sure the DPL/RPL/CPL are all equal to 3.

Good luck.

pcmattman · Post by **pcmattman** » Sat Jul 21, 2007 2:14 am

As I said though, OR-ing with 3 (11b) gave me a page fault...

AJ · Post by AJ » Sat Jul 21, 2007 2:22 am

Hi,

Where does the page fault occur (what is CR2)? Could it be that you are a) Trying to use data or b) Trying to use a stack which is in kernel space. I know I had stack problems when I first did this too, as I hadn't allowed for a user mode page for the stack.

Als, make sure that the u/s bit is set in all page table entries and page directory entries where your user task is accessing data/code.

A possible way to find a solution would be to make your paging mechanism set the user bit in all PDE's/PTE's on every page in operation (including in kernel space). Then, modify it so that the paging bit is not set for kernel pages - if you get a PFE again, you then know you are trying to access a kernel page you shouldn't be.

Hope this makes sense!
Adam

pcmattman · Post by **pcmattman** » Sat Jul 21, 2007 2:24 am

It occurs on the entry point of the program, where I know the pages are not set to supervisor.

CR2 == 0x400000.

AJ · Post by AJ » Sat Jul 21, 2007 2:33 am

OK,

If CS RPL = 3 and
SS = DS = ES = FS = GS RPL = 3 and
All PTEs and PDEs have bit 3 set,

I don't know what's happening. Do you have a link to the source of your page in routine and your task switching routine?

Sorry I can't be more helpful

pcmattman · Post by **pcmattman** » Sat Jul 21, 2007 2:35 am

AJ wrote:All PTEs and PDEs have bit 3 set

Wait, bit 3 set? Won't that make it supervisor?

Edit: OK, I set bit 3 on all pages relating to usermode, now I'm faulting on 0xB8000 which is a kernel (ie. supervisor) mapping. This is good.

Edit 2: Here's a shot of the kernel in action:

Code: Select all

[NULL] Idle task has started.
[FAT ] Initializing FAT32 structures... Done!
Welcome to Mattise!
Version 1.1, ALPHA

I've been rudely interrupted by the processor with this message for you:
Page Fault
Crash at 0x  40001e   EFLAGS: 0x   13286 Process: 1
Registers at time of crash:
------------------------------------------
PAGE FAULT, error code information:
Error because of a privilege violation                                          
Was a read                                                                      
Processor was in supervisor mode                                                
Reserved bit violation: no                                                      
Wasn't caused by an instruction fetch                                           
------------------------------------------                                      
Interrupt number: 14                                                            
EAX: 0x       0   EBX: 0x       0 ECX: 0xffbff000 EDX: 0x       0               
EBP: 0xffbfefe8   ESP: 0x  115f84 ESI: 0x       0 EDI: 0x       0               
Segments at time of crash:                                                      
CS: 0x      1b  DS: 0x      23  ES: 0x      23                                  
FS: 0x      23  GS: 0x      23  SS: 0x      23                                  
Control registers:                                                              
CR0: 0x80000011   CR2: 0x   b8000 CR3: 0x  171000

Any hints would be really nice

(By the way, the ESP shown there is the kernel stack, the EBP value is the user stack with some stuff in it).

AJ · Post by AJ » Sat Jul 21, 2007 2:53 am

Glad it helped. I did exactly the same with my multitasker (among all the other mistakes) - I assumed that it was a 'Supervisor Set Bit', rather than a 'User Set Bit'.

Adam

nooooooooos · Post by **nooooooooos** » Sat Jul 21, 2007 5:06 am

Thats really strange becaus I know a lot of Tutorials which explain the funtion of this bit interchanged...

Noooooooooooos

AJ · Post by AJ » Sat Jul 21, 2007 6:05 am

For anyone interested, it's section 3.7.6 in intel manual 3a.

pcmattman · Post by **pcmattman** » Sat Jul 21, 2007 5:05 pm

AJ wrote:For anyone interested, it's section 3.7.6 in intel manual 3a.

I read that and interpreted that if bit 3 was set the PDE/PTE was supervisor. Of course I didn't notice this in the kernel because it runs at ring0.

AJ · Post by AJ » Mon Jul 23, 2007 2:16 am

OK - given your second edit above, I don't quite understand the problem (this may me be being slow

).

You now have set bit 3 of your user code which runs without a problem until you try to print something directly to video RAM. At that point, you get a PFE occurring at 0xB8000, because of a privilege level problem, but you have already stated that 0xB8000 is paged at supervisor level.

If I have summarised the problem correctly, you can only access video RAM from either your kernel (running in PL0), or by setting bit 3 of the 0xB8000 page from your kernel before switching to the user task (which I wouldn't advise).

I would suggest doing it by handling a syscall to the kernel and writing to video RAM from there.

Sorry if I have got the wrong end of the stick..
Adam

pcmattman · Post by **pcmattman** » Mon Jul 23, 2007 2:27 am

There is a system call to print to the screen, I was just trying to circumvent it (at the same time getting the opcodes for the operation).

That was also before the newlib's printf() worked (I had stdout as descriptor 0, not stdin

).