您好，欢迎来到教程Hypervisor From Scratch的第六部分。在这一部分中，我们将学习如何使用定制的虚拟机管理程序虚拟化已经运行的系统。与其他部分一样，本部分依赖于前面的部分，因此请务必先阅读它们。

在第六部分中，我们将了解如何通过配置 VMCS 虚拟化当前运行的系统。我们使用VMX的监控功能来检测CPUID等重要指令的执行（并从用户模式和内核模式更改CPUID的结果），检测不同控制寄存器上的修改，并描述不同微架构上的VMX功能，谈论MSR位图和许多其他很酷的东西。

在前面的部分中，我们实现了一个名为 AdjustControl 的函数。 这是每个虚拟机管理程序的重要组成部分，因为您可能希望在具有不同微架构的许多不同处理器上运行虚拟机管理程序。 我们应该了解我们的处理器功能，以避免未定义的行为和 VM-Entry 错误。

这是这样工作的； 首先，向以下函数发送MSR，该MSR指示需要修改的VMCS控制。 然后我们查看相应的MSR来了解该控件的1设置和0设置。 最后，我们删除不支持的位，将强制设置为1，并配置控制。

如果您还记得上一部分，我们在 4 种情况下使用了上述函数。

简要浏览一下 附录 A -VMX 能力报告工具 说明 即可了解有关保留控制和默认设置的 。 在 Intel VMX 中，某些控制被保留，并且必须设置为由处理器确定的特定值（0 或 1）。 保留控件必须设置的特定值是其 默认设置 。 这些类型的设置因每个处理器和微体系结构而异，但一般来说，存在三种类型的类：

现在，有针对 pin-based VM-execution controls, primary processor-based VM-execution controls, VM-Entry Controls, VM-Exit Controls and secondary processor-based VM-execution controls 的单独功能 MSR 。

这些 MSR 用于检查上述控制：

在所有上述 MSR 中，位 31:0 指示这些控制允许的 0 设置。 如果 MSR 中的位 X 被清除为 0，则 VM 条目允许控制 X（位 X）为 0； 如果 MSR 中的位 X 设置为 1，则如果控制 X 为 0，则 VM 进入失败。同时，位 63:32 指示这些控制允许的 1 设置。 如果 MSR 中的位 32+X 设置为 1，VM 条目允许控制 X 为 1； 如果 MSR 中的位 32+X 清除为 0，且控制 X 为 1，则 VM 进入失败。

虽然也有一些例外，但是现在你应该明白AdjustControls的用途了，它首先读取VM执行控件对应的MSR，然后调整0设置和1设置，并返回最终结果。

我建议查看专门针对 MSR_IA32_VMX_PROCBASED_CTLS 和 MSR_IA32_VMX_PROCBASED_CTLS2 的 AdjustControls 结果，因为您可能会无意中将某些位设置为 1，因此，您应该制定一个根据您的特定处理器处理某些 VM 退出的计划。

对于 CR0、 IA32_VMX_CR0_FIXED0 MSR（索引 486H）和 IA32_VMX_CR0_FIXED1 MSR（索引 487H）以及对于 CR4 IA32_VMX_CR4_FIXED0 MSR（索引 488H）和 IA32_VMX_CR4_FIXED1 MSR（索引 489H）指示如何在 VMX 操作中设置 CR0 和 CR4 中的位。 如果 IA32_VMX_CRx_FIXED0 中的 X 位为 1，则 CRx 的该位在 VMX 操作中固定为 1。 类似地，如果 IA32_VMX_CRx_FIXED1 中的位 X 为 0，则 CRx 的该位在 VMX 操作中固定为 0。 通常情况下，如果 IA32_VMX_CRx_FIXEDx 中的位 X 为 1，则 IA32_VMX_CRx_FIXED1 中的该位也为 1。

在第五部分中，我们了解了如何配置不同的 VMCS 字段并最终在guest上下文下执行我们的指令 (HLT)。 这部分与上一部分类似，只是在一些VMCS属性上有一些细微的变化。 让我们回顾一下并看看其中的差异。

您需要知道的第一件事是，您必须为每个核心创建不同的堆栈，因为我们将同时虚拟化所有核心。 每当发生 VM-exit时就会使用这些堆栈。

从上面的代码可以看出，我们使用 VmmStack分别为每个核心（定义在 VIRTUAL_MACHINE_STATE结构）。

所有其他的事情，比如清除 VMCS 状态、加载 VMCS 和执行 VMLAUNCH 都与前面的部分完全相同，因此我不想再次描述它们，而是看看负责准备我们当前核心进行虚拟化的函数。

从上面的代码来看， SetupVmcsAndVirtualizeMachine是新的，所以让我们看看这个函数里面有什么。

VMCS 字段并不是什么新鲜事。 我们应该配置这些字段来管理虚拟化核心的状态。

除VMCS控制位的配置外，所有VMCS字段与最后部分相同：

如您所见，对于 CPU_BASED_VM_EXEC_CONTROL ，我们设置了 CPU_BASED_ACTIVATE_MSR_BITMAP ； 这样，我们就可以启用 MSR BITMAP 过滤器（本部分稍后介绍）。 设置此字段在某种程度上是强制性的。 正如您可能猜到的，Windows 在简单的内核执行期间访问大量 MSR，因此如果我们不设置此位，那么我们将在每次 MSR 访问时退出，当然，我们的 VMX Exit-Handler 会被调用，从而清除该位为零会使系统速度大大减慢。

对于 SECONDARY_VM_EXEC_CONTROL ，我们使用 CPU_BASED_CTL2_RDTSCP 启用 RDTSCP ，使用 CPU_BASED_CTL2_ENABLE_INVPCID 启用 INVPCID ， 使用CPU_BASED_CTL2_ENABLE_XSAVE_XRSTORS 启用 XSAVE 和 XRSTORS 。

这是因为我在我的Windows 10 1809中运行上述代码，看到Windows将 INVPCID 和 XSAVE 用于其内部使用（在支持这些功能的处理器中），所以如果你在虚拟化核心之前没有启用它们，那么它可能导致错误。

请注意， RDTSCP 将处理器时间戳计数器的当前值读入 EDX:EAX 寄存器，并将 IA32_TSC_AUX MSR（地址 C0000103H）的值读入 ECX 寄存器。 该指令向 RDTSC 添加排序，并使性能测量比 RDTSC 更准确。

INVPCID 根据进程上下文标识符 (PCID) 使转换后备缓冲区 (TLB) 和分页结构高速缓存中的映射无效，并且 XSAVE 将处理器状态组件全部或部分保存到位于 XSAVE 由 指定的内存地址的 区域目标操作数。

请确保检查您在这些字段中输入的最终值，因为您的处理器可能不支持所有这些功能，因此您必须实现一些附加功能或忽略其中一些功能。

除了用作GUEST_RSP的GuestStack之外，该函数中没有留下任何内容。稍后我会告诉你在这个论证中要加入什么。

好的，现在的问题是我们可以从哪里启动虚拟机管理程序。 我的意思是，如何保存特定核心的状态，然后在其上执行 VMLAUNCH 指令，然后继续执行其余部分。

为此，我更改了例程DrvCreate，因此您必须CreateFile从用户模式应用程序进行更改（我将在稍后讨论）。事实上，DrvCreate就是负责将所有核心置于VMX状态的函数。首先，它查询核心的计数，然后为每个核心执行必要的初始化。

我们的微型驱动程序设计用于单核、两核、三核甚至所有核。 从下面的代码中可以看到，它查询逻辑处理器计数。

您可以编辑此行以虚拟化一定数量的核心或仅虚拟化特定核心，但上述代码默认虚拟化所有核心。

有一个函数叫做RunOnProcessor.该函数将处理器 ID 作为其第一个参数，EPTP 指针（在第四部分中解释）作为第二个参数，以及调用的特定例程VmxSaveState作为第三个参数。

RunOnProcessor 将处理器亲和力设置为特殊内核，然后将 IRQL 提升到调度级别，以便 Windows 调度程序无法启动来更改上下文； 因此，它运行我们的例程，当它从 VmxSaveState 返回时，当前运行的核心被虚拟化，因此它可以将 IRQL 降低到之前的水平。 现在，Windows 可以在虚拟机管理程序的管理下继续正常执行。 IRQL 代表中断请求级别，这是一种特定于 Windows 的机制，用于管理中断或按级别赋予优先级，因此提高 IRQL 意味着您的例程将以比正常 Windows 代码（PASSIVE_LEVEL 和 APC_LEVEL）更高的优先级执行。 欲了解更多信息，您可以访问这里。

这 RunOnProcessor代码如下所示。

VmxSaveState必须保存状态并调用另一个函数， VirtualizeCurrentSystem.

我们必须在汇编文件（VMXState.asm）中使用此函数，因为所有 VmxSaveState功能 都是在汇编中实现的。 对于使用C函数，在汇编中，我们可以编写函数名称并使用EXTERN关键字。

以下示例显示了如何在程序集文件中使用 VirtualizeCurrentSystem。

VMXSaveState是这样实现的（在汇编中）：

它首先保存所有寄存器的状态，由于Shadow Space而减去堆栈以实现快速调用函数，然后将RSP放入R8并调用VirtualizeCurrentSystem。 RSP 应该移到 R8 中（正如我在 GuestStack 中告诉您的那样），因为 x64 fastcall 参数应该按以下顺序传递：RCX、RDX、R8、R9 + Stack。 这意味着该函数的第三个参数是当前 RSP，并且该值将用作 VMCS 中的 GUEST_RSP。

如果上述函数运行没有错误，我们永远不应该到达 ret 指令，因为该状态稍后将在另一个名为 VmxRestoreState 的函数中继续。

正如我们在VirtualizeCurrentSystem中看到的，它最终调用SetupVmcsAndVirtualizeMachine，GUEST_RIP指向VmxRestoreState，因此当前核心中执行的第一个例程是VmxRestoreState。

这个函数的定义如下：

在上面的函数中，首先，我们删除 Shadow Space 并恢复寄存器状态。

当我们回到 RunOnProcessor，是时候降低 IRQL 了。

这个函数会被调用很多次（基于我们的逻辑核心数），最终，我们所有的核心都处于VMX操作下，现在我们处于 VMX non-root操作 中。

基于上述假设，我们必须在用户模式应用程序中进行一些细微的更改，以便在加载驱动程序后，它可以用于通知内核模式代码开始并最终结束加载虚拟机管理程序。

在对供应商和虚拟机管理程序的存在进行一些检查之后，现在我们必须从内核模式调用 DrvCreate，它是通过 CreateFile 用户模式函数调用的。

CreateFile为我们提供了一个句柄，可以在我们未来的函数中使用它来与我们的驱动程序交互。 尽管如此，每当我们关闭应用程序或调用 CloseHandle在用户模式下， DrvClose会在内核中自动调用。 DrvClose关闭虚拟机管理程序并将状态恢复到之前的状态（未虚拟化）。

配置完上述所有字段后，就可以使用 VMX 的监控功能了。 我们将了解这些功能在安全应用程序或逆向工程任务中有何独特之处。 作为额外资源，您可以使用 HyperDbg Debugger 。 HyperDbg 是一个基于虚拟机管理程序的调试器，它允许我们在调试过程中使用大部分 VT-x 功能。

VM-execution control fields 包括一组 4个CR3-target values and a CR3-target count。 如果您还记得我之前在 SetupVmcsAndVirtualizeMachine 中介绍的 VMCS 字段，您可以看到以下几行：

Intel 定义 CR3-Target 控件如下：

如果源操作数与这些值之一匹配，则在 VMX non-root操作中执行 MOV 到 CR3 不会导致 VM-exit。 如果 CR3-target count为 n，则仅考虑前 n 个 CR3 目标值。

使用这个功能的实现是这样的：

我没有任何好的例子来说明此控件在常规 Windows 中如何发挥作用，因为每个进程都有数千个 CR3 更改。 不过，我的一位朋友告诉我，它在科学项目的一些特殊情况下使用，以提高整体性能。

CPUID 是无条件导致VM退出的指令。 如您所知， 使用CPUID 是因为它允许软件发现处理器的详细信息。 它还用于刷新不支持 RDTSCP 等指令的处理器的管道，因此它们可以使用 CPUID + RDTSC 并使用 CPUID 作为屏障。

每当任何特权级别的任何软件执行 CPUID 指令时，都会调用我们的 vm-exit 处理程序，现在我们可以决定要向软件显示的内容。 例如，之前我发表了一篇文章“ 击败恶意软件的反虚拟机技术（基于CPUID的指令） ”。 本文介绍如何通过更改 CPUID 指令结果的方式配置 VMware Workstation，以便具有反 VM 技术的恶意软件无法了解它们正在虚拟化环境中执行。 VMware Workstation（和其他虚拟环境）执行相同的机制来处理 CPUID 。 在下面的示例中，我只是将寄存器的状态（VM-exit之前的寄存器状态）传递给 HandleCPUID。 该函数决定请求的 CPUID 是否应具有修改后的结果或仅执行直通原始结果。

处理每个 VM 退出（由 VMX 非 root 中执行 CPUID 引起）的默认行为是使用 _cpuidex 获取原始结果，这是 CPUID 的内部函数。

如您所见，VMX non-root 本身无法执行 CPUID ，我们可以在 VMX root 模式下执行 CPUID 并将结果返回给 VMX non-root 模式。

我们需要检查 RAX（CPUID 索引）是否为 1。 这是因为有一个指示位可以显示当前机器是否在虚拟机管理程序下运行。 与许多其他虚拟机一样，我们设置当前虚拟机管理程序位（本示例中使用的常量类似于 hyper-v 的位 HYPERV_HYPERVISOR_PRESENT_BIT）以表明我们正在虚拟机管理程序下运行。

还有关于虚拟机管理程序提供商的第二次检查。 我们将其设置为“ HVFS ”以表明我们的虚拟机管理程序是[ H ]yper[ V ]isor[ F ]rom[ S ]cratch。

我们可以轻松地向上述代码添加更多检查并自定义我们的 CPUID 过滤器，例如更改我们的计算机供应商字符串等。

最后，我们将它们放入寄存器中，以便客户每次执行例程时都能得到正确的结果。

将以上所有代码放在一起，我们有以下功能：

它在某种程度上类似于 CPUID 的指令级挂钩。 此外，通过配置primary and secondary processor-based controls，您可以为许多其他重要指令提供相同的处理功能。 稍后我们将描述其中一些说明。

作为有关虚拟机管理程序的额外说明， CPUID 是导致用户模式或内核模式软件通过使用增量定时旁路攻击来检测虚拟机管理程序是否存在的方法之一。 它源于这样一个事实：该指令会导致无条件 VM-exit，在虚拟机管理程序的情况下，与非虚拟机相比，执行时间要长得多。

这些攻击的描述超出了本文的范围，但如果您有兴趣，可以阅读 本文 中有关这些攻击的详细说明。

以下是在 VMX 非 root 操作中导致 VM-exit的指令列表，具体取决于 VM 执行控件的设置。 - CLTS - ENCLS - HLT - IN, INS/INSB/INSW/INSD, OUT, OUTS/OUTSB/OUTSW/OUTSD. - INVLPG - INVPCID - LGDT, LIDT, LLDT, LTR, SGDT, SIDT, SLDT, STR - LMSW - MONITOR - MOV from CR3/CR8, MOV to CR0/1/3/4/8 - MOV DR - MWAIT - PAUSE - RDMSR, WRMSR - RDPMC - RDRAND, RDSEED - RDTSC, RDTSCP - RSM - VMREAD, VMWRITE - WBINVD - XRSTORS, XSAVES

检测和处理控制寄存器 (CR) 修改是虚拟机管理程序提供的重要监视功能之一。

想象一下，如果有人利用 Windows 内核（或任何其他操作系统）并想要取消设置控制寄存器位之一（比方说写保护或 SMEP ）； 然后虚拟机管理程序会检测到此修改并阻止进一步执行。

现在是时候实现我们的功能了。

首先，让我们阅读 VMCS 的 GUEST_CR 和 EXIT_QUALIFICATION。。

正如您所看到的，下图显示了我们如何解释退出资格

请注意，EXIT_QUALIFICATION 在某种程度上是一个通用 VMCS 字段，在某些情况下（例如由无效 VMCS 布局、控制寄存器修改、I/O 位图和其他事件导致的 VM 退出），它提供有关 VM 退出原因的附加信息。

从上图可以看出，我们根据EXIT_QUALIFICATION制作一些变量来描述情况。

每当由 MOV CRx、REG 等指令导致 VM 退出时，我们必须从 VMX-root 模式手动修改 guest VMCS 的 CRx。 以下代码显示如何使用 VMWRITE 更改 VMCS 的 GUEST_CRx 字段。

否则，我们必须从guestVMCS（不是主机控制寄存器，因为它可能不同）读取 CRx ，然后将其放入相应的寄存器中（在调用VM退出处理程序时我们保存的寄存器中），然后继续 VMRESUME 。 这样，guest就认为它执行了 MOV reg, CRx成功地。

把它们放在一起，我们有一个像这样的函数：

之所以需要实现像HandleControlRegisterAccess这样的函数，是因为有些处理器对一些processor-based VM-execution controls有1-settings，比如CR3-Load Exiting和CR3-Store Existing，所以我们必须自己管理这些类型的VM-exit ，但是如果我们的处理器可以在没有这些设置的情况下继续运行，则强烈建议减少 VM 退出的数量并避免配置导致此类 VM 退出的设置，因为现代操作系统访问控制寄存器很多； 因此，它会带来严重的性能损失。

这里的一切都取决于您是否设置了Primary Processor Based controls的第 28 位。

在支持“使用 MSR 位图”VM-execution control设置为 1 的处理器上，VM-execution control字段包括四个连续 MSR 位图的 64 位物理地址，每个位图大小为 1 KB。

Intel SDM中MSR位图的定义非常清楚，所以我只是从原始手册中复制它们。 阅读完它们后，我们将开始实现它们并将它们放入我们的虚拟机管理程序中。

OK，我们把上面这句话带入代码中。 首先，我们将为 MSR VM 退出编写处理程序。

处理 MSR 阅读

在我们的直通虚拟机管理程序中，如果 RDMSR 或 WRMSR 中的任何一个导致 VM-exit，我们必须手动执行 RDMSR 或 WRMSR 并将结果设置到寄存器中。 因此，我们有一个功能来管理 RDMSR，例如：

您可以看到它只是检查 MSR 的健全性，然后执行 RDMSR 并最终将结果放入 RAX 和 RDX （因为非虚拟化的 RDMSR 会做同样的事情）。

处理MSR写入

还有另一个处理 WRMSR VM-exits 的函数：

该函数的功能很简单。 尽管如此，值得您自己尝试的一件事是避免在 CPU_BASED_VM_EXEC_CONTROL 中设置 CPU_BASED_ACTIVATE_MSR_BITMAP，您将看到所有 MSR 读取和修改都会导致 VM 退出，原因如下：

这次，我们必须将所有内容传递给上述函数并记录这些 VM-exit，以便您可以看到 Windows 在虚拟机管理程序中运行时使用的 MSR。 正如我上面告诉你的，Windows 执行大量的 MSR 指令，因此它会使你的系统慢得多，超出你的承受能力。

好的，让我们回到 MSR 位图。 我们需要两个函数来设置 MSR 位图的位。

另一个函数用于检索特定位。

现在是时候根据上述有关 MSR 位图的描述将所有内容收集到一个函数中了。 以下函数首先检查 MSR 的健全性； 然后，它更改目标逻辑核心的 MSR 位图（这就是为什么我们同时保存 MSR 位图的物理地址和虚拟地址、VMCS 字段的物理地址和虚拟地址，以方便修改和将来的释放）。 如果是低MSR的读（RDMSR），则设置MSR位图虚拟地址中的相应位，如果是低MSR的写（WRMSR），则修改MSR位图+ 2048（如Intel手册中所述）并精确对于高 MSR（0xC0000000 和 0xC0001FFF 之间）也是如此，但不要忘记减法（0xC0000000），因为 0xC000nnnn 不是有效位。

还要记住一件事，当前只有上述 MSR 范围在 Intel 处理器中有效，因此即使任何其他 RDMSR 和 WRMSR 也会导致 VM-exit。 尽管如此，这里的健全性检查是强制性的，因为guest可能会发送无效的 MSR 并导致整个系统崩溃（在 VMX root-mode下）。 在以后的部分中，当我们了解事件注入时，我们将在客户机尝试访问无效 MSR 的情况下，通过向客户机注入事件来模拟物理机的行为。

是时候关闭虚拟机管理程序并将处理器状态恢复到运行虚拟机管理程序之前的状态了。

就像我们进入虚拟机管理程序 (VMLAUNCH) 的方式一样，我们必须将 C 函数与汇编例程结合起来，以保存状态、执行 VMXOFF、释放所有先前分配的池，最后恢复状态。

该例程的 VMXOFF 部分应在 VMX 根模式下执行。 您不能只在驱动程序函数之一中执行 __vmx_vmxoff 并期望它关闭虚拟机管理程序，因为 Windows 及其所有驱动程序当前都在 VMX 非 root 中运行，因此执行任何 VMX 指令就像使用一个 VM 退出出于以下原因。

要关闭虚拟机管理程序，最好使用我们的 IRP 主要功能之一。 在我们的例子中，我们使用了 DrvClose因为每当我们设备的句柄关闭时它总是会收到通知。 如果您还记得上面的内容，我们使用我们的设备创建一个句柄 CreateFile ( DrvCreate），现在是时候使用以下命令关闭我们的句柄了 DrvClose.

上面的函数没有什么特别的； 只有 TerminateVmx被添加。

此函数类似于执行 VMLAUNCH 的例程，只是它运行的是 VMXOFF 。

如您所见，它在所有正在运行的逻辑核心上执行 RunOnProcessorForTerminateVMX。 然后，它使用 MmFreeContigouslyMemory 释放为 VmxonRegion、VmcsRegion、VmmStack 和 MsrBitmap 分配的缓冲区，当然，还会在需要时将物理数据转换为虚拟数据.

请注意，如果虚拟化了部分核心（不是全部），则必须修改此函数。

在 RunOnProcessorForTerminateVMX 中，我们必须告诉 VMX 根操作有关关闭虚拟机管理程序的信息。 正如我告诉你的，这是因为我们无法在常规驱动程序例程中执行任何 VMX 指令，而且很明显，如果没有任何机制来处理这种情况，或者我们没有足够的特权来卸载虚拟机管理程序。

有多种方法可以告诉我们的 VMX 根操作有关 VMXOFF 的 信息，但在我们的例子中，我们将使用 CPUID 。

现在你肯定知道执行CPUID会导致VM退出。 现在，在我们的 CPUID 退出处理程序例程中，我们管理每当执行 RAX = 0x41414141 和 RCX = 0x42424242 的 CPUID 时，我们就必须返回 true，并且它向调用者表明虚拟机管理程序需要关闭。

还有另一项 DPL 检查，以确保 RAX = 0x41414141 和 RCX = 0x42424242 的 CPUID 仅在系统特权级别（内核模式）下执行。 因此，任何用户模式应用程序都无法卸载我们的虚拟机管理程序。

现在，我们的 RunOnProcessorForTerminateVMX 会分别执行 CPUID 并将调整后的值存入所有内核的寄存器中。

在 EXIT_REASON_CPUID 处理程序中，我们知道如果处理程序返回 true，那么我们必须将其关闭，因此我们应该考虑其他一些事情。 例如，Windows 期望稍后从 GUEST_RIP 继续，并且每当 VM 退出处理程序返回时都需要其先前的 GUEST_RSP； 因此，我们必须将它们保存在某些位置，并在以后使用它们来恢复 Windows 状态。

另外，我们必须增加GUEST_RIP，因为我们想恢复CPUID之后的状态。

从第五部分，您可能知道MainVmexitHandler是从VmexitHandler调用的（来自VMExitHandler.asm的汇编函数）

让我们详细看看。

首先，我们必须 extern 一些先前定义的变量。

现在我们的VmexitHandler是这样工作的，每当VM退出发生时，目标逻辑核心就会执行HOST_RIP中定义的VmexitHandler，并且我们的RSP设置为HOST_RSP，然后我们必须保存所有寄存器。 这意味着我们必须创建一个允许我们读取和修改类似 C 结构中的寄存器的结构。

只需按 GUEST_REGS 结构顺序推送所有寄存器，并将 RSP 作为第一个参数推送到 MainVmexitHandler (Fastcall RCX)，然后对 Shadow Space 进行一些减法。

您可以在这里看到 VmexitHandler：

从上面的代码来看，当我们从 MainVmexitHandler 返回时，我们必须检查 MainVmexitHandler（在 RAX 中）的返回结果是否告诉我们关闭虚拟机管理程序或继续。

如果需要继续，恢复寄存器状态并跳转到我们的VmResumeInstruction函数。

VmResumeInstruction 执行 __vmx_vmresume 并且处理器将 RIP 寄存器设置为 GUEST_RIP。

但如果需要关闭怎么办？

然后根据AL寄存器，跳转到另一个名为VmxoffHandler的函数。 该函数执行VMXOFF指令，关闭虚拟机管理程序（在当前逻辑核心中），然后将寄存器恢复到我们将它们保存在VmexitHandler中的先前状态。

我们在这里唯一要做的就是将堆栈指针更改为 GUEST_RSP（我们将它们保存在 g_GuestRSP 中）并跳转到 GUEST_RIP（保存在 g_GuestRIP 中）。

现在一切都完成了，我们执行正常的 Windows（驱动程序）例程； 我的意思是，在从 RunOnProcessorForTerminateVMX 执行的最后一个 CPUID 之后开始执行，但现在我们不处于 VMX 操作中。

将以上所有代码放在一起，现在我们必须管理不同类型的VM-exit，因此我们需要修改之前解释的（第5部分）VM-exit处理程序； 如果您忘记了，请查看第五部分（ VM-Exit Handler ），它完全相同，但由于各种退出原因而具有不同的操作。

我们需要管理的第一件事是检测在VMX non-root操作中执行的每条VMX指令； 可以使用以下代码来完成：

正如我在 DbgPrint 中告诉您的，执行这些类型的 VMX 指令最终会导致 BSOD，因为在我们的虚拟机管理程序到来之前可能会检查虚拟机管理程序是否存在。 因此，执行这些指令的例程（当然，它来自内核）可能认为它可以执行这些指令。 如果它没有很好地管理它们（这很常见），您将看到 BSOD。 因此，您必须找出调用此类指令的原因并手动禁用它们。

如果您配置了任何基于 CPU 的控件，或者您的处理器支持任何 CR 访问退出控件的 1 设置，则可以使用以下 VM-exit来管理它们。

MSR 访问也是如此。 如果我们没有设置任何 MSR 位，每个 RDMSR 和 WRMSR 都会导致退出，或者如果我们设置了任何位 MsrBitmap，那么我们必须使用以下 RDMSR 函数来管理它们：

管理WRMSR 的代码：

如果你想检测I/O指令的执行情况，那么：

如果您想使用上述功能，请不要忘记设置足够的基于 CPU 的控制字段。

对我们来说最后重要的是 CPUID 处理程序。 它调用HandleCPUID（如上所述），如果结果为true，则保存GUEST_RSP和GUEST_RIP，以便这些值可以用于恢复目标核心中执行VMXOFF后的状态。

现在是时候测试我们的虚拟机管理程序了。

首先，我们必须加载我们的驱动程序。

然后我们的 DriverEntry被调用，所以我们必须运行用户模式应用程序来虚拟化所有核心。

你可以看到，如果你按任意键或关闭这个窗口，它会调用 DrvClose并恢复状态（ VMXOFF ）。

上图为驱动日志。 此时，所有核心均位于虚拟机管理程序之下。

现在让我们测试虚拟机管理程序是否存在。 对于本例，我使用 Immunity Debugger 通过自定义 EAX 执行 CPUID。 您可以使用任何其他调试器或任何自定义应用程序。

我们必须手动将 EAX 设置为 0x40000001 或 HYPERV_CPUID_INTERFACE然后执行 CPUID 。

上图显示了没有虚拟机管理程序的 HYPERV_CPUID_INTERFACE。

最后，我们必须关闭用户模式应用程序窗口，因此它在所有内核上执行 VMXOFF。 让我们再次测试一下上面的例子。

您可以看到实际结果已经出现，因为我们不再处于虚拟机管理程序之下。

为了测试 MSR 位图，我创建了一个本地内核调试器（使用 WinDbg）。 在WinDbg中，我们可以执行rdmsr和wrmsr命令来读写MSR。 这与使用系统驱动程序执行 RDMSR 和 WRMSR 完全相同。

在 VirtualizeCurrentSystem 函数中，添加以下行。

在WinDbg本地调试器中，我们执行了上述命令，在远程调试器中，我们可以看到结果如下，

可以看到，检测到RDMSR的执行。 我们的虚拟机管理程序运行完美！

就是这样，伙计们。

在这一部分中，我们了解了如何通过为每个逻辑核心单独配置 VMCS 字段来虚拟化已运行的系统。 然后，我们使用虚拟机管理程序更改 CPUID 指令的结果并监视对控制寄存器或 MSR 的每次访问。 在这部分之后，我们的虚拟机管理程序几乎准备好用于实际项目了。 后续部分是关于使用扩展页表（如前面第 4 部分所述）。 我相信虚拟机管理程序中的大多数令人兴奋的工作都可以使用 EPT 来执行，因为它具有特殊的日志记录机制，例如页面读/写访问检测以及您将在下一部分中看到的许多其他很酷的东西。

下一部分见。

[1] 第 3C 卷 – 第 24 章 –（虚拟机控制结构 ( https://software.intel.com/en-us/articles/intel-sdm )

[2] cpu-internals ( https://github.com/LordNoteworthy/cpu-internals )

[3] RDTSCP — 读取时间戳计数器和处理器 ID ( https://www.felixcloutier.com/x86/rdtscp )

[4] INVPCID — 无效进程上下文标识符 ( https://www.felixcloutier.com/x86/invpcid )

[5] XSAVE — 保存处理器扩展状态 ( https://www.felixcloutier.com/x86/xsave )

[6] XRSTORS — 恢复处理器扩展状态监控器 ( https://www.felixcloutier.com/x86/xrstors )

[7]什么是IRQL？ （ https://blogs.msdn.microsoft.com/doronh/2010/02/02/what-is-irql/ ）

[注意]传递专业知识、拓宽行业人脉——看雪讲师团队等你加入！