Create sandboxes directly from snapshots

[ludfjig]

Builds a ready-to-use MultiUseSandbox directly from an Arc<Snapshot> without going through UninitializedSandbox + evolve(). Building block for OCI-backed snapshot loading on a follow-up branch.

Adds:

• HostFunctions newtype around the internal FunctionRegistry. default() pre-registers HostPrint, empty() starts empty.
• MultiUseSandbox::from_snapshot(snap, host_funcs, cfg). Snapshot is the source of truth for layout. cfg is honored for non-layout fields (timeouts, debug info, interrupt retry delay).
• Snapshot records host function metadata. from_snapshot rejects registries missing functions or with mismatched signatures. Pre-init snapshots record nothing and accept any registry, matching the UninitializedSandbox contract.
• gdb support extended to sandboxes built via from_snapshot.

Recommend to review commit-by-commit

[Copilot]

Pull request overview

Adds the ability to construct a MultiUseSandbox directly from an Arc<Snapshot>, bypassing UninitializedSandbox + evolve(). Snapshots now record the host functions registered at capture time, and the new constructor validates that the provided host-function set is a superset of those required. The gdb entry-point breakpoint mechanism is reworked into a one-shot tracked on the VM so it works for both Initialise and Call snapshots.

Changes:

• New HostFunctions newtype (with default() pre-registering HostPrint and new() empty) and MultiUseSandbox::from_snapshot(snap, host_funcs, cfg).
• Snapshot now carries HostFunctionDetails and exposes validate_host_functions to reject missing/mismatched signatures; pre-init snapshots accept any registry.
• Gdb support: replaces VcpuStopReason::EntryPointBp with a one_shot_entry_bp field cleared by the run loop; entry breakpoint installed for both Initialise and Call entries; new gdb e2e test for snapshot path.

Reviewed changes

Copilot reviewed 14 out of 14 changed files in this pull request and generated 7 comments.

Show a summary per file

File	Description
src/hyperlight_host/src/sandbox/initialized_multi_use.rs	Implements from_snapshot, layout-override warning, snapshot host-function plumbing, and tests.
src/hyperlight_host/src/sandbox/snapshot/mod.rs	Adds host_functions field and validate_host_functions; updates constructors and tests.
src/hyperlight_host/src/sandbox/host_funcs.rs	Adds HostFunctions newtype and with_default_host_print; changes register_host_function to infallible; tweaks From impl.
src/hyperlight_host/src/sandbox/uninitialized.rs	Uses with_default_host_print and removes redundant register_print call in new.
src/hyperlight_host/src/func/host_functions.rs	Adapts Registerable impls to infallible registry call; adds HostFunctions impl.
src/hyperlight_host/src/mem/mgr.rs	Plumbs HostFunctionDetails into snapshot(); inherits snapshot_count in from_snapshot.
src/hyperlight_host/src/mem/layout.rs	Widens visibility of several layout fields and MAX_MEMORY_SIZE.
src/hyperlight_host/src/lib.rs	Re-exports HostFunctions.
src/hyperlight_host/src/hypervisor/hyperlight_vm/x86_64.rs	Sets up one-shot entry breakpoint covering Initialise and Call.
src/hyperlight_host/src/hypervisor/hyperlight_vm/mod.rs	Adds one_shot_entry_bp field and run-loop logic to clear it on first hit.
src/hyperlight_host/src/hypervisor/gdb/mod.rs	Removes VcpuStopReason::EntryPointBp variant.
src/hyperlight_host/src/hypervisor/gdb/event_loop.rs	Drops handling for the removed variant.
src/hyperlight_host/src/hypervisor/gdb/arch.rs	vcpu_stop_reason no longer takes/uses the entrypoint, becomes side-effect-free classifier.
src/hyperlight_host/examples/guest-debugging/main.rs	Extracts gdb test helpers and adds test_gdb_from_snapshot.

[jsturtevant]

LGTM, I've left a few comments and one missing testing that needs a fix

[jsturtevant]

I assume the snapshot manager does other validation? Should this validation live with that validation? if not are we missing validation? Can a maliciously crafted snapshot bypass any assumptions we have about the memory layout?

[ludfjig]

There's no way to create malicious snapshots (yet). Right now they are completely opaque structs to the user. This will change when we load them from disk though (future PR, where I add a lot of validation)

[jsturtevant]

(future PR, where I add a lot of validation)

Glad to hear we are planning this. What if a malicious guest does something (writes some handcrafted assembly) and we take a snapshot with that in there?