-
Notifications
You must be signed in to change notification settings - Fork 150
Description
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.
Metadata
Metadata
Assignees
Labels
Type
Projects
Status