Skip to content

Ensure that system registers don't leak information between uses of a sandbox #791

Closed

Description

@syntactically

Because most hypervisors treat setting up or destroying a partition as a heavy operation, reusing a Hyperlight sandbox for a different workload does not create a new partition. Traditionally, we tried to reset the state of the pre-existing partition with the evolve/devolve abstraction, which has now been replaced by snapshots.

Both approaches have focused mostly on ensuring the state of memory is reset to the expected new state, and have left resetting register state to the entry sequence for the next sandbox function that is called. On amd64, we happen to use calls that do in fact reset all general-purpose and floating point registers. However, we do not reset all system registers/MSRs/etc. Unfortunately, this means that co-operating guests (or e.g. a compromised guest and a malicious guest) could pass data between uses of a sandbox by leaving it in otherwise-unused system registers across a snapshot restore. We should (a) insofar as this is possible, disable access to system registers that we are not using in the guest and (b) ensure that every register that is available to a guest is backed up during snapshotting and restored during restore.

Activity

  1. modified the milestones: Upcoming, v0.10.0 on Aug 27, 2025
  2. self-assigned this
    on Sep 19, 2025
  3. modified the milestones: v0.10.0, v0.11.0 on Oct 1, 2025
  4. modified the milestones: v0.11.0, v0.12.0 on Nov 5, 2025
  5. modified the milestones: v0.12.0, v0.13.0 on Dec 16, 2025
  6. modified the milestones: v0.13.0, v0.14.0 on Feb 18, 2026
  7. jsturtevant commented on Feb 18, 2026

    @jsturtevant
    Contributor

    progress on this was made in #1120 and we have the remaining work in #991

  8. ludfjig commented on Feb 19, 2026

    @ludfjig
    Contributor

    Upcoming HVCALL_SCRUB_PARTITION should help with this (on hyperv)

  9. simongdavies commented on Mar 11, 2026

    @simongdavies
    Member

    Wait for mshv crate support or add ourselves

  10. syntactically commented on Mar 11, 2026

    @syntactically
    MemberAuthor

    If we are planning on scrub on mshv and msr filtering on KVM, do we have a plan of record for WHP?

  11. ludfjig commented on Mar 11, 2026

    @ludfjig
    Contributor

    If we are planning on scrub on mshv and msr filtering on KVM, do we have a plan of record for WHP?

    Deleting the vcpu and recreating it should be possible (and fast) on WHP, and cover more than just MSRs. I'm not sure if there is state in the VM too that needs to be reset, would need to check

  12. ludfjig commented on Mar 12, 2026

    @ludfjig
    Contributor

    there's also this internal api https://docs.rs/windows-sys/latest/windows_sys/Win32/System/Hypervisor/fn.WHvResetPartition.html, which is slower than delete + recreate vcpu

  13. syntactically commented on Aug 3, 2026

    @syntactically
    MemberAuthor

    @ludfjig @jsturtevant we should be able to close this now that #991 is in?

  14. modified the milestones: v0.14.0, v0.17.0 on Aug 4, 2026
  15. moved this from In Progress to Done in Hyperlight Roadmapon Aug 4, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Labels

area/securityInvolves security-related changes or fixeslifecycle/confirmedBug is verified or proposal seems reasonable

Type

Projects

Milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions