Repository navigation
Improve guest exception handling to prevent infinite loops #1118
Description
When the guest exception handler itself fails (due to corrupted stack, unmapped memory etc.), the guest enters an unrecoverable state— causing either an infinite page fault loop (hang) or a triple fault (crash). This occurs because:
- The exception handler entry point requires a working stack (for context_save!() pushes)
- The Rust handler uses format!() which allocates on the heap
- There's no detection of nested/recursive exceptions
A triple fault is not a terrible outcome as at least the guest terminates but having the infinite page loop is more of a problem, if the host is monitoring execution and kills the guest via the InterruptHandle then it should be able to successfully terminate the guest , but if it is not doing this then a badly behaved guest could cause resource (CPU) starvation.
There are a couple of things that we can do to protect against this:
Configure a small permanent fixed stack in the ISS that can be used for a double fault handler.
Detect exception handler re-entrancy and exit immediately with outb data that the host can translate to a DoubleFault error.
This is another reason that we should consider not allowing guest code to run in ring 0.
Activity
[-]Improve guest exception handling to infinite loops[/-][+]Improve guest exception handling to prevent infinite loops[/+]syntactically commentedon Dec 16, 2025
An IST exception stack is added in 6211e98, since the interrupt handler becomes involved in growing the main stack, and the handler always runs on the top of that stack since there isn't any expected reentrancy.
Separately, I think that it is a bug that the handler can allocate. When doing the snapshot CoW, it is careful not to allocate before that is done since that would go badly, but it would be preferable not to allocate at all, and I don't believe there is a strong reason to be allocating.
Having the assembly entry stub check for reentrancy is a reasonable idea, but I'm unsure if it is worth it if the exception handler is small and well-behaved (which it probably should be).