Repository navigation
Replace generic HyperlightError::Error variant with specific error types to improve sandbox poisoning accuracy #998
Description
The sandbox poisoning mechanism relies on accurate error information and strong typing to determine when a sandbox has entered an inconsistent state requiring recovery. Currently, the HyperlightError::Error variant is a generic catch-all error type that can be created using the new_error! macro.
The problem is that HyperlightError::Error can be (and is) used for situations that should poison the sandbox, but the error type doesn't provide enough information for the poisoning logic to make the correct determination. This creates a safety hole where:
- Critical errors that leave the sandbox in an inconsistent state might be wrapped in generic error variants
- The poisoning mechanism cannot distinguish between benign errors and those that compromise sandbox state
- Sandboxes that should be poisoned may continue to be used
Solution
Replace all instances of HyperlightError::Error with specific, strongly-typed error variants that accurately describe the error condition.
As an aside, we should probably distinguish between internal errors and public errors. Right now all errors are pub because they all are part of the same enum. I think splitting errors by something like file/module/struct/method is a good idea in general.
Activity
syntactically commentedon Nov 5, 2025
Another question that I have that could be answered as part of looking through error cases for this issue: we currently have host->guest and guest->host calls both unconditionally return a
Resultsum type with aHyperlightError::Errorcase, making both directions of calls fallible. I wonder if most/all of the cases where an error is produced on these code paths actually ought to be fatal to the sandbox, which would allow removing some of the hyperlight result wrappers (entirely, on the guest->host call path, and on the guest side of the host->guest call path, so that the only error returns from a host->guest call are in the "the sandbox is poisoned due to an implementation bug or guest compromise, probably record this, etc" regime, not things that need to be handled "normally")ludfjig commentedon Jan 26, 2026
Some work towards this was done in #1162 which added richer errors for all HyperlightVm methods