OSDev.org

Previously, I used this code which always seems to generate a tripple-fault:
With PAE-paging enabled, this no longer works (mov cr3,eax generates a protection fault).

This code should work even with PAE-enabled: (some pseudo-code)
But maybe there is an easier way to do it?

Why would you want to generate a triple fault? There are better ways to reset the computer.

Yes, it's like asking any safest way to detonate explosive, so that I can clean my house.

Triple fault is meant for unsolvable issue.
Think about someone run your OS within an VM and want to reboot the machine, then the VM tell the user the computer has some serious problem that cannot be resolved.

I think you know the proper way to reboot/shutdown, and you just want to seek for quick & dirty ways.

There are just too many ways to do a reset. On old computers, it was done with keyboard port, but that is no longer safe as some PCs don't even have the keyboard controller. On newer PCs, ACPI can give you a clue, but I don't want to be dependent on a working ACPI. The main reason I want no dependency on ACPI is that the crash debugger (which tries to create a stable environment after a fatal error) also need to do a reboot, and cannot count on ACPI working, and thus need a simple way that always works.

About the only effective way that seems to work on both very old and brand new PCs is to generate a tripple fault. I've actually not seen any PC that lack the RESET logic for tripple fault.

Besides, I first try the keyboard-way, and then resort to tripple fault if the former is not effective.

And VMs should know that a tripple fault means you should reset me, since that logic exist on every PC.


Updated logic for tripple fault:
This logic zeros IDT descriptors for protection fault and double fault, and then generates a protection fault.

rdos wrote:This logic zeros IDT descriptors for protection fault and double fault, and then generates a protection fault.

I think a simpler way is to mess up the kernel stack, so that #SS > #DF (if you use gate, mess up that stack too) > #TF, and don't need to alter the IDT.

Hi,

Set the IDT limit to zero, and then trigger any interrupt. This guarantees that the interrupt will generate a GPF (fetching an IDT entry beyond the IDT limit), which will guarantee a double fault then triple fault for the same reason.

Note that this will work even if you use a "task gate" for the double fault handler, or have exception handlers that attempt to recover from severely borked situations.


Cheers,

Brendan

I like the set IDT limit to 0 method, but some future processor might think this is invalid and might instead of doing the instruction generate a protection fault, much like when loading an invalid CR3 in PAE-mode. After all, Intel manuals states that certain exception handlers should be present.

It seems like clearing the contents of the IDT would have a similar effect, and couldn't cause an accidental GPF/double fault as long as interrupts are disabled while you're doing it.

What about returning to real mode and jumping to FFFF:0?

Hi,

linguofreak wrote:What about returning to real mode and jumping to FFFF:0?

That resets almost nothing; which means that you can expect problems afterwards caused by the firmware making assumptions about the contents/state of various things (including the contents of MSRs, MTRRs, IOMMUs, ACPI's controller, PCI configuration space, PICs/APICs, timers, and more or less everything else you could think of).


Cheers,

Brendan