-

[koemeet]

[tandasat]

Does this reproduce where ever the code snippet is added to VM-exit handling code? VmmpHandleGdtrOrIdtrAccess already has the same code already and I believed it worked on Win10 CU.

[koemeet]

[koemeet]

[tandasat]

I quickly looked into why it bug checked. I believe the code is hitting the rule #GP .. If an attempt is made to write a 1 to any reserved bit in CR3. described under MOV—Move to/from Control Registers. Changing lower 12bits of CR3 when the PCID Enable bit of CR4 is clear would meet that condition as PCID is disabled and those lower bits would be treated as reserved (or must be zero bits).

Try temporarily enable the PCID bit while changing CR3.

[koemeet]

[koemeet]

[tandasat]

The issue was that VmcsField::kGuestCr3 could store an user-mode CR3 (_KPROCESS::UserDirectoryTableBase) which could not be used in the kernel-mode when VM-exit occurred in the user-mode.

For example, if a process whose kernel address space is shadowed due to the Meltdown patch, its CR3 value does not map full kernel address space when it is running in the user-mode. When such a process triggers VM-exit from the user-mode (eg, via CPUID or SIDT), a processor stores the user-mode CR3 into kGuestCr3, instead of a kernel-mode CR3. If a VMM tries to load such value, it would be missing some critical kernel virtual address space and trigger exceptions causing the bug check.

To address this issue, you have to get the kernel CR3 in VM-exit handling code. I added VmmpGetKernelCr3 you can use for that work.

[koemeet]

[tandasat]

You are welcome 👍