IRET to ring 3

jal · Post by **jal** » Tue Mar 04, 2008 2:42 pm

Quick question, to which I couldn't find anything in 5 minutes of Googling and checking the Wiki (although I may have overlooked something, in which case a simple STFW is ok): if I use software based task switching in a flat 4G memory model, what should the code and data segment GDT entries look like, and what the CS and DS values on the stack? Currently I have for ring 0 access set to 9A for code and 92 for data, and for ring 3 FA and F2 respectively. On the stack there's 8*(index) | 3 (for RPL 3) for both. This works, kinda, since Bochs dumps these values when tripple faulting at the first instruction.

Related question: when does a tripple fault occur, even if I've set up all exception handlers (and the fault does not occur inside one)?

JAL

Combuster · Post by **Combuster** » Tue Mar 04, 2008 3:22 pm

Some random remarks
- An IRET across rings only changes CS and SS. It leaves DS ES etc unchanged.
- Having exception handlers does not mean triplefaults can't happen. The processor can get additional faults when trying to call said exception handler. Most notoriously, a borked TSS will cause a triplefault because it can't switch to a ring0 stack. A borked GDT will cause a triplefault because it can't load the values for CS or SS, A borked IDT will not get you into a handler at all, and borked pagetables make your exception handlers dissapear.
- 5 minutes googling isn't really searching.
- instead of only STFWing, also RTFM

jal · Post by **jal** » Wed Mar 05, 2008 1:43 am

Combuster wrote:Some random remarks
- An IRET across rings only changes CS and SS. It leaves DS ES etc unchanged.

Indeed, but I included the other segment registers on the stack as well as the normal regs. It seems fairly problematic not changing DS when going from ring 0 -> 3 (in fact, I got a nice GP fault when not doing so).

- Having exception handlers does not mean triplefaults can't happen. (...)

Thanks, I'll check those that may apply.

- 5 minutes googling isn't really searching.

No, not even close. Although usually I can get all the answers to a random poster's questions by Googling for at most 5 minutes. Maybe I've become lazy :).

- instead of only STFWing, also RTFM :wink:

Yeah, yeah, I know I should've included that one :). I've gone through most if not all sections of the FM that seemed to apply, but couldn't find an answer to my questions. Better check again, methinks.

JAL

bewing · Post by **bewing** » Wed Mar 05, 2008 3:45 am

- 5 minutes googling isn't really searching.

Googling is an excessively scattershot method of trying to determine/fix an OS development problem. I would think that the entire function of the existence of osdev and its wiki would be to eliminate the need for googling for that purpose -- at least as a theoretical ideal.

jal · Post by **jal** » Wed Mar 05, 2008 6:46 am

bewing wrote:Googling is an excessively scattershot method of trying to determine/fix an OS development problem. I would think that the entire function of the existence of osdev and its wiki would be to eliminate the need for googling for that purpose -- at least as a theoretical ideal.

Indeed, that's why I usually give up after five minutes, as the chance of finding anything you need dramatically decreases with the time you're searching. Unfortunately, I couldn't find it in the Wiki either (checked there first of course).

JAL

zaleschiemilgabriel · Post by **zaleschiemilgabriel** » Wed Mar 05, 2008 9:45 am

Read the Intel manuals (or similar) for info on the GDT access settings. Other than that, software task switching could be implemented any way you want, so it's pretty much up to you what's stored on the stack.
I have a general rule not to store any kernel memory management info on the user-mode stack. All that will be stored as internal kernel data.

Related answer: http://en.wikipedia.org/wiki/Triple_fault
That took me 0.41 seconds to find on Google:
Results 1 - 100 of about 519,000 for triple fault. (0.41 seconds)

jal · Post by **jal** » Wed Mar 05, 2008 2:02 pm

zaleschiemilgabriel wrote:Related answer: http://en.wikipedia.org/wiki/Triple_fault
That took me 0.41 seconds to find on Google:
Results 1 - 100 of about 519,000 for triple fault. (0.41 seconds)

Yes, but I wasn't Googling for that (nor does the Wikipedia page really help much). I've found the cause of the tripple fault, it was a stupid mistake. Still some code to clean up...

JAL

zaleschiemilgabriel · Post by **zaleschiemilgabriel** » Thu Mar 06, 2008 7:28 am

jal wrote:it was a stupid mistake

It usually is...

I'm glad you solved it yourself and didn't even need Google to do it!