nVMX: Policy on VM-entry checks KVM intends to support

nVMX: Policy on VM-entry checks KVM intends to support

[Manuel Andreas]

Hi all,

I've built a tool that allows me to scrutinize the VMLAUNCH emulation of KVM.
With this, I am able to find a variety of VMCS12 configurations that will pass
KVM's own implemented VM-entry checks and eventually create an architecturally 
invalid VMCS02 that will fail its hardware VM-entry.

A brief overview of some of these cases:
- Missing checks on GUEST_RFLAGS
- Missing checks on GUEST_RIP
- Missing check on GUEST_CR4.PCIDE for 32 bit guests
- Missing checks related to guest segments
- Missing checks for event injection related fields
- Missing canonical checks on GUEST_SYSENTER_EIP/ESP

I am aware that a failed hardware VM-entry on VMCS02 is not directly an issue on its own, as it is
caught in L0 and forwarded to L1 for handling.

However, many of these cases would still bring forth incorrect emulation behavior.
For instance, lets assume an L1 guest has configured its VMCS12 such that both the GUEST_SYSENTER_ESP
and the VM-entry MSR load address are invalid. Then, a real hardware VM-entry on such a VMCS would result in EXIT_REASON_INVALID_STATE.
In contrast, since KVM does not check the GUEST_SYSENTER_ESP to be canonical, it would pass the guest-state checks and
move on to the MSR loading, which would eventually fail and forward the VM-exit EXIT_REASON_MSR_LOAD_FAIL to L1. Therefore, KVM does not
correctly emulate hardware.

Further, I can think of other cases (and believe have found at least one such case) that lead to incorrect emulation behavior due to missing/incorrect VM-entry checks:
- L1 launches an architecturally valid VMCS12, but the merging creates an invalid VMCS02 and KVM forwards a failed VM-entry to L1
- L1 launches an architecturally _in_valid VMCS12, but the merging creates a valid VMCS02 and the VM-entry succeeds. 

These cases would seem to contradict (or make one of such exceptions?) this statement from the maintainer docs:
"With few exceptions, KVM *must* honor architectural behavior, therefore it's implied that KVM behavior is emulating SDM and/or APM behavior."
Therefore, indicating that these cases are all to be treated as bugs in KVM.

Now, what's confusing me is that in `nested_vmx_run` I see the following comment:

/*
 * The nested entry process starts with enforcing various prerequisites
 * on vmcs12 as required by the Intel SDM, and act appropriately when
 * they fail: As the SDM explains, some conditions should cause the
 * instruction to fail, while others will cause the instruction to seem
 * to succeed, but return an EXIT_REASON_INVALID_STATE.
 * To speed up the normal (success) code path, we should avoid checking
 * for misconfigurations which will anyway be caught by the processor
 * when using the merged vmcs02.
 */

which one could interpret as KVM intentionally attempting to validate as little of the VMCS12 as possible?
This entirely makes sense to me if KVM simply prioritizes performance rather than 100% emulation correctness.

However, I am then once more confused by some other source code comments.
For instance, `__vmx_guest_state_valid` hosts the following comment:

/* TODO:
 * - Add checks on RIP
 * - Add checks on RFLAGS
 */

which indicates to me that one would ideally have those VM-entry checks for completeness sake,
just nobody got around to implementing those yet?

So in the end I would simply like to know what VM-entry checks KVM actually cares about, such that I don't
need to waste your (or my) time on submitting useless patches.

Thanks and best,
Manuel