After some testing, I found that the hEvent values are consistent between runs because they are assigned sequentially on startup. The critical sections for VMMDev and VGA are created directly after the processor-related critical sections. So long as the processor chipset doesn’t change, these should remain constant.
经过一些测试，我发现这些 hEvent 值在运行之间是一致的，因为它们是在启动时按顺序分配的。 VMMDev 和 VGA 的关键部分直接在处理器相关的关键部分之后创建。只要处理器芯片组不改变，这些就应该保持不变。
I will note here that there are other critical sections that could potentially be used, but I chose to write my exploit using the VMMDev critical section.
我在这里要指出的是，还有其他可能使用的关键部分，但我选择使用 VMMDev 关键部分来编写我的漏洞利用。
First, we use our bit clearing bug to turn 0x23 into 0x21. Subsequently, whenever there are two threads, one holding the critical section for VMMDev and one holding the critical section for VGA, when either thread releases its critical section it can wake up a thread waiting for either device. Our plan is to use this race condition to wake a thread waiting for VGA prematurely, which is to say, while some other thread is still using VGA.
首先，我们使用我们的位清除错误来变成 0x23 0x21 .随后，每当有两个线程时，一个保存 for VMMDev 的关键部分，一个保存 VGA 的临界部分，当任一线程释放其关键部分时，它可以唤醒等待任一设备的线程。我们的计划是使用此争用条件来过早唤醒等待的 VGA 线程，也就是说，当其他一些线程仍在使用 VGA 时。
This is not good enough yet, though. Even if we hit the race, VirtualBox throws a SigTrap shortly thereafter. This is because when the racing thread locks the critical section, it changes NativeThreadOwner. When the first thread tries to unlock the critical section, the NativeThreadOwner does not match, causing the error.
不过，这还不够好。即使我们参加了比赛，VirtualBox 也会在不久之后抛出一个 SigTrap 。这是因为当赛车线程锁定关键部分时，它会发生变化 NativeThreadOwner 。当第一个线程尝试解锁关键部分时，不 NativeThreadOwner 匹配，从而导致错误。
