Virtual Machine Introspection (VMI)
https://revers.engineering/7-days-to-virtualization-a-series-on-hypervisor-development/
https://tandasat.github.io/blog/2023/07/31/intel-vt-rp-part-2.html
- Intel’s hardware assisted virtualization technology (originally Vanderpool, later renamed VT-X/VMX) is a set of processor features which add support for virtualized operating systems without the use of emulation. In the typical ring protection design of an x86 processor running a modern operating system, there are two main rings of operation:
- With the invention of VT-X, a new mode of operation was introduced in hardware to provide the VMMs with a more privileged position over the guest operating systems that it manages. This new processor mode is named VMX Root Mode, and it executes at a mode more privileged than Ring 0, sometimes informally known as “Ring -1”. In this higher privileged mode, the hypervisor uses its privilege to isolate memory and devices of multiple running operating systems into separate containerized environments while still achieving close to native processor execution speeds.
- On Intel processors support for virtualization is provided as a processor operation called VMX operation.
During VMX operation there are two operation states – root operation and non-root operation. Much like transitions from user to kernel operations when a VMM is not present, the transitions while in VMX operation are called VMX transitions. These transitions are caused by a variety of conditions, the main two we’ll be covering in this introduction are VM entries and VM exits.
It’s important to note that VM entries are primarily performed by a set of instructions introduced only while in VMX operation, and in the VMM. If a guest attempts to perform a VM entry it will actually cause a VM exit and transition into VMX root operation for the VMM to handle the use of a privileged instruction. As mentioned above a set of instructions are introduced while in VMX operation, if an application attempts to execute them outside of VMX operation they’ll be met with a UD (invalid opcode exception).
Let’s start with defining our virtual CPU context by identifying what unique objects we know of belong to any given virtual CPU:
- It’s own set of control registers.
- It’s own set of debug registers.
- It’s own set of model specific registers.
- It’s own set of special registers (GDTR, LDTR, IDTR)
- It’s own status register (RFLAGS)
- It’s own general purpose registers (RAX-R15)
- It’s own segment information
These are objects that belong to all logical processors and are independent of whether or not they’re in VMX operation. The vCPU context is used to represent the operational state of a virtual processor. Each virtual processor has their own set of items listed above and below.
- A processor context (vCPU context; container for important structures for VMX operation)
- A VMXON region
- A VMCS region
- A processor stack