Skip to contentSkip to conversation

Why is double_fault serviced by a trap gate?

DISCUSSION Petr Vandrovec 2 participants 2 messages Dec 7, 2000

lore
Share & tools
lore
#0 lore raw
Quoted 18 lines · Richard B. Johnson
Quoted 8 lines · Andi Kleen
Quoted 7 lines · On Thu, Dec 07, 2000 at 04:04:21PM +0000, [email protected] wrote:

Why is double_fault serviced by a trap gate? The problem with this is that any double-fault caused by a stack-fault, which is the usual reason, becomes a triple-fault. And a triple-fault results in a processor reset or shutdown making the fault damn near impossible to get any information on.

Quoted 8 lines
Quoted 3 lines

Oughtn't the double-fault exception handler be serviced by a task gate? And similarly the NMI handler in case the NMI is on the current stack page frame?

Sounds like a good idea, when you can afford a few K for a special NMI/double fault stack. On x86-64 it is planned to do that.

Quoted 4 lines

Well, at least on current ix86 processors it can't. Attempting to use a task gate appears to be a trick to cause the exception to be handled on the current stack. The hardware protection hierarchy won't let this happen. You need to have a stack that is not accessible

No. If interrupt uses task gate, task switch happens. Nothing is stored in context of old process except registers into TSS. There is only one (bad) problem. If you want to get it 100% proof (it is not needed for double fault, but it is definitely needed for NMI, as NMI is very often on SMP ia32), each CPU's IRQ vector must point to different task, otherwise you can get TSS in use during doublefault, leading to triplefault again...

Quoted 3 lines

from the mode that will be trapped. Otherwise, a user could crash the machine by setting ESP to 0 and waiting for the next context- switch or timer-tick.

Yes. Currently if any ESP related problem happens in kernel, machine silently reboots without any message. With task gate (as Jeff Merkey proposed some months ago, btw), you can even suspend offending task and recover from it... I think that also bluesmoke should use task gate, but I did not read documentation on this yet.
Best regards,
Petr Vandrovec [email protected]

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
Please read the FAQ at http://www.tux.org/lkml/

#1 lore raw
Quoted 6 lines · Petr Vandrovec

No. If interrupt uses task gate, task switch happens. Nothing is stored in context of old process except registers into TSS. There is only one (bad) problem. If you want to get it 100% proof (it is not needed for double fault, but it is definitely needed for NMI, as NMI is very often on SMP ia32), each CPU's IRQ vector must point to different task, otherwise you can get TSS in use during doublefault, leading to triplefault again...

Well, I expect wasting a descriptor and a page of memory for the purpose
of a TSS is not a big problem.

Quoted 2 lines

Yes. Currently if any ESP related problem happens in kernel, machine silently reboots without any message. With task gate (as Jeff Merkey proposed

You might handle the stack fault with a task gate, actually, but I'm not
sure it's worth the hassle. Handling just the double fault should be sufficient.

Quoted 3 lines

some months ago, btw), you can even suspend offending task and recover from it... I think that also bluesmoke should use task gate, but I did not read documentation on this yet.

Yep. An MCE is an abort like a double-fault, so the CPU state might be
corrupted (by definition -- I have no idea whether it really happens).

Signature · 8 lines
+  Maciej W. Rozycki, Technical University of Gdansk, Poland   +
+--------------------------------------------------------------+
+        e-mail: [email protected], PGP key available        +

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
Please read the FAQ at http://www.tux.org/lkml/