Prevent MSRs from leaking across calls to MultiuseSandbox::restore

[ludfjig]

The goal is to prevent guest state to persist across snapshot-restores.

• Kvm: directly disallows read/writes to msrs using KVM_X86_SET_MSR_FILTER. A denied access raises #GP in the guest, surfaces as GuestAborted, and poisons the sandbox.
• Hyperv (mshv+whp): The read/writes are allowed (no way to prevent it (intercept exists but doesn't cover all msrs)). Instead restore will reset set msrs using a hardcoded list of MSRs that are known to be writeable. The baseline values of these MSRs are captured on vm-creation. A limitation is that any MSR that is guest-writable and not in this list, has the potential to leak.

Future work:

• When scrub-parition hvcall is ready, we will switch to it, which is guaranteed reset all MSRs. (won't exist for kvm though, which is fine).
• address Unify mshv and whp partition features #1685
• batch calls to read/write msrs in vm creation, to improve perf via decreasing number of hv call. The reason it's all done 1 at at time right now it because on hyperv, read/write multiple msrs is either "all or nothing" so not trivial to batch, since it's expected that some should fail (and we need to know exactly which!). Could also be addressed by above item Unify mshv and whp partition features #1685 to perhaps avoid msr probing entirely, or at least make the number of probed msrs fewer

Will mark ready for review once KVM releases new version, which should include newly added KVM_X86_SET_MSR_FILTER vm ioctl that this PR depends on, see rust-vmm/kvm#359

[Copilot]

Pull request overview

This PR prevents x86_64 model-specific register (MSR) state from persisting across snapshot restores by adding explicit MSR capture/reset semantics to snapshots, enforcing an MSR allow-list contract, and (on KVM) denying guest MSR access by default via an MSR filter.

Changes:

• Capture MSR reset state into Snapshot (and snapshot-on-disk format), and restore it during MultiUseSandbox::from_snapshot / MultiUseSandbox::restore.
• Add SandboxConfiguration::allow_msrs (bounded allow list) and enforce allow-list compatibility on restore (destination must be a superset).
• Implement backend-specific MSR handling: KVM deny-by-default filtering + violation reporting; MSHV/WHP MSR read/write support for reset.

Reviewed changes

Copilot reviewed 22 out of 22 changed files in this pull request and generated 5 comments.

Show a summary per file

File	Description
src/tests/rust_guests/simpleguest/src/main.rs	Adds guest-side RDMSR/WRMSR and SWAPGS helpers for host MSR tests.
src/hyperlight_host/src/sandbox/snapshot/mod.rs	Extends Snapshot with optional captured MSRs and snapshot allow list.
src/hyperlight_host/src/sandbox/snapshot/file/mod.rs	Persists/loads MSR fields and validates msrs/allowed_msrs consistency.
src/hyperlight_host/src/sandbox/snapshot/file/config.rs	Adds MSR fields to OCI snapshot config and serde tests/schema pin updates.
src/hyperlight_host/src/sandbox/snapshot/file_tests.rs	Adds end-to-end disk snapshot tests for MSR capture/compat/allow-list rules.
src/hyperlight_host/src/sandbox/initialized_multi_use.rs	Captures MSRs on snapshot and restores them on from_snapshot/restore + extensive MSR tests.
src/hyperlight_host/src/sandbox/config.rs	Introduces MSR allow-list storage and capacity-checked allow_msrs.
src/hyperlight_host/src/mem/mgr.rs	Threads MSR state through snapshot construction.
src/hyperlight_host/src/hypervisor/virtual_machine/whp.rs	Adds WHP MSR register mapping + get/set MSRs for reset.
src/hyperlight_host/src/hypervisor/virtual_machine/mshv/x86_64.rs	Adds MSHV MSR mapping + get/set MSRs for reset.
src/hyperlight_host/src/hypervisor/virtual_machine/mod.rs	Extends VirtualMachine with MSR read/write APIs + validation helpers/errors.
src/hyperlight_host/src/hypervisor/virtual_machine/kvm/x86_64.rs	Implements KVM MSR filter configuration, filtered-exit handling, and KVM MSR get/set.
src/hyperlight_host/src/hypervisor/regs/x86_64/special_regs.rs	Adds test asserting x2APIC stays disabled by default.
src/hyperlight_host/src/hypervisor/regs/x86_64/msrs.rs	New MSR reset table + snapshot validation logic and related constants/tests.
src/hyperlight_host/src/hypervisor/regs/x86_64/mod.rs	Exposes the new MSR module via pub(crate) use.
src/hyperlight_host/src/hypervisor/hyperlight_vm/x86_64.rs	Captures baseline MSR reset state at VM creation and implements restore logic.
src/hyperlight_host/src/hypervisor/hyperlight_vm/mod.rs	Wires KVM MSR violations into RunVmError and stores msr_reset in HyperlightVm.
src/hyperlight_host/src/error.rs	Adds HyperlightError::{MsrReadViolation, MsrWriteViolation} and marks them poisoning on KVM.
Justfile	Adds ignored host-dependent MSR audit test recipes to test-isolated.
docs/msr.md	Documents MSR reset set, backend differences, validation rules, and limitations.
CHANGELOG.md	Adds breaking-change entry for MSR allow-list + restore behavior.
.github/workflows/ValidatePullRequest.yml	Disables matrix fail-fast for PR validation workflow.

[syntactically]

This looks functionally quite good! I left a number of review comments inline, which are mostly about improving clarity / things whose function was not obvious to me.

Beyond what I've explicitly called out in the review comments, I think the high level structure of both the code and the documentation could be a little bit clearer. For the code, I felt like it was not always clear what was HV-specific and what wasn't, and there was just generally a lot of jumping around to follow e.g. the initialisation sequences and compare kvm vs mshv for things like allowlist filtering. For the documentation, there are currently a lot of sections that are all level 2 headings, some of which are related to each other and some of which are not, and it feels like it jumps between different things a few times, making it harder to follow; probably there is some way to use heading structure to organise it a bit more nicely) could be a bit clearer.

[ludfjig]

I think I addressed your comments. I moved the hyperv specific code to be called from respective backend (whp/mshv) but since it's duplicate code the code is still located outside the backends. Would you prefer the duplicate code appraoch inside each backend isntead?

[syntactically]

I didn't have a chance to actually read this yet. A couple of immediate reactions from the comment replies you wrote to me:

• I am still not sure I completely understand the semantics of the allow set; I left an inline reply on that
• I also had a couple of quick follow-up questions about what testing you did for the vmexit/vmenter emulation

Would you prefer the duplicate code appraoch inside each backend isntead?

Duplicating the code does indeed not seem great. I might go for a mshv_shared module at the same level as kvm/mshv/hvf/whp that has any shared logic for the mshv/whp stuff? This is getting into the weeds of taste now, so feel free to ignore.

[syntactically]

This looks good now!