Re: [PATCH 4/7] KVM: nVMX: Process each host MSR entry at most once when unwinding failed VM-Entry

[Jim Mattson]

On Tue, Nov 3, 2026 at 12:59 PM Sean Christopherson <seanjc@xxxxxxxxxx> wrote:
>
> On Tue, Nov 03, 2026, Jim Mattson wrote:
> > On Mon, Nov 2, 2026 at 4:10 PM Sean Christopherson <seanjc@xxxxxxxxxx> wrote:
> > >
> > > On Mon, Nov 02, 2026, Jim Mattson wrote:
> > > > KVM needs to do better.
> > >
> > > Meh, KVM is doing pretty darn good, all things considered.  Yeah, this code sucks.
> > > But I'm not convinced the alternatives suck less.  We've gotten the set of missed
> > > consistency checks down to effectively zero, module the TPR mess that I do test
> > > by running warn_on_missed_cc=true.
> >
> > I don't understand the TPR mess. The SDM says, "With the exception of
> > fields corresponding to virtualized APIC registers (defined in Section
> > 32.1.1), software may modify the virtual-APIC page referenced by the
> > current VMCS of a logical processor in VMX non-root operation. (This
> > is an exception to the general requirement given in Section 27.11.4.)"
>
> Oh, I wasn't aware of that.  I agree, that gives us an "out" for vTPR, mostly.
>
> > I would argue that this prohibits changes to VTPR between KVM's
> > software VM-entry checks and hardware VM-entry to VMCS02. If the
> > hardware VM-entry fails because VTPR has changed, section 27.11.4
> > gives KVM the freedom to implement whatever "unpredictable behavior"
> > we like. Yes, that probably does include loading MSR values from the
> > VM-exit MSR-load list, but why complicate things?
> >
> > Something like returning to userspace with
> > KVM_INTERNAL_ERROR_EMULATION following a prohibited write to an active
> > VTPR seems far easier--and cleaner. What am I missing?
>
> My biggest concern is that KVM could kill L1 if an L2 coerces L1 into trying
> VMLAUNCH/VMRESUME with invalid state.  KVM simply can't *know* that an unexpected
> VM-Fail was due to the vTPR wrinkle.  Even if KVM re-checked state, it's possible
> for the vTPR to be "restored" to a good value.

The only way that I can see for L2 to coerce L1 into trying VM-entry
with invalid control fields or invalid host-state fields is by
exploiting an L1 nested virtualization bug (i.e. L2 is running an L3).
In any case, if L0 has already performed the checks in software, then
failure of the checks in hardware implies either (a) misbehavior on
the part of L1 or (b) an emulation error in L0.

> I.e. if KVM exits to userspace with KVM_INTERNAL_ERROR_EMULATION, then there's a
> non-zero chance of a false positive.  KVM could exit to userspace if and only if
> it caught the guest red-handed, but then we'd still need this horrific code for
> the other cases, so that seems rather pointless.

Let's go back to the Xen example, since by your argument any L1 can be
victimized. If an L2 VM somehow coerced L1 Xen into trying VM-entry
with invalid control fields or invalid host-state fields, and somehow
L0's software checks passed, but the hardware checks on VMCS02 failed,
you would continue to run the L1 VCPU with L2's SPEC_CTRL MSR. Surely,
the possibility of a malicious L2 exfiltrating data from L1 with the
assistance of L0 has to be worse than the abnormal termination of L1?

(Note that I'm just playing devil's advocate here. I don't actually
buy your argument.)

> warn_on_missed_cc helps, but in practice it can't detect cases for which we don't
> have test coverage.  So *if* there was a bug that could be exploited by L2 to DoS
> L1, odds are good warn_on_missed_cc didn't catch that hypothetical bug either.
>
> Maybe with AI we can be 100% confident that KVM performs all of the VM-Fail
> consistency checks?  Again, I'm not opposed to alternative approaches, but at the
> same time I don't feel a sense of urgency.

KVM *must* perform all of the control field and host-state field
consistency checks. Otherwise, we risk priority inversion with
"illegal guest state." If KVM is missing any of these checks, then it
has an "internal error."