stack, page fault and tripple fault question

[Krom]

i have been thinking about make my own os(who doesn't think about this here?) for a long time. I'm reading the Intel 386 book and i see that using TSS is possible to have a very strong protection. After looking trought internet i found that almost nobody uses TSS and change tasks by hand(faster and better performance, but less protection against faults).

I want to have everithing clear before writing anything. Here is the explanation of the possible problem and what would happen.

We have one perfect task running on a 386+ computer with X(128 Mb) Mb memory with the kernel loaded at some high memory(eg: 0xC0000000), we use paging in the memory manager. The top of the stack is something below the kernel's memory(like 0xB0000000). We have more tasks running on the system so some of the pages are not present because of virtual memory. The our perfect task call one procedure(using CALL in X86). Doing this, the processor will push the old IP in the stack(to return here with RET instruction) but when in try to push the IP the page is not present, and we well have one PAGE FAULT. Then it will try to go to the page fault esception handler, and it will try to push CS, IP and FLAGS, but still the page is not present, so we well have DOUBLE FAULT, again try to push something and TRIPLE FAULT.

ok, this is only my imagination, could it happen? how can we avoid this problem?

i suppose that we can check thet dirty flag, of the last page we are using of the stack and make the next present, but it will take more time to check, and still is not error free, because some procedure could reserve more than a page of the stack (using SUB ESP, X) and still we will have this problem.

also i would like to know if ?'m right or i'm thinking about something impossible.

[Pype.Clicker]

What you described *can* happen and it happened to me .
The solution i found is to use a separate expand-down segment for each kernel stack (and giving each the appropriate limit, but the same base == base of code&data to keep the flat C programming model). When a kernel stack overflow occurs, there is no more page fault but instead a stack fault, which is handled by a dedicated TSS (and so we get rid of that circular dependency

[Krom]

I have read again the part about the esceptions(in the 386 book) and i found that this will happend if the interrupt is at the same privilege level than the program that is running, because use the same stack. But if the interrupt is in another privilege level, this will not happend because the stack change automatic to the one of the privilege 0 from the information in the TSS. Anyway if the fault is inside the PL0 still will tripple fault.

Looks like that to have total protection the only way is a new TSS task(like what you do). Your way to manage this is good for user, and kernel task, but i dont like the idea of limiting the stack, i preffer to have a stack with no limit and wait until page not present fault happen, reserve one page of memory for the task and continue with the task.

What do you think about this way of manage the stack? (it is for users programs, because is "supposed" that kernel will be ok, lol)

[Pype.Clicker]

i've used a page-based stack protection for user programs (which is quickly handled by the generic trap-gate EXC14) and a segment-based stack protection for the kernel (so that i don't need to redirect #PF exception to a TSS or the system would be way too slow. kernel stack exceptions are an abnormal condition, so i decided to give them favour treatment.