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

[Sean Christopherson <seanjc@google.com>]

On Tue, Nov 03, 2026, Jim Mattson wrote:
> On Tue, Nov 3, 2026 at 12:59 PM Sean Christopherson <seanjc@google.com> wrote:
> > > 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).

Hmm, I agree L2 would be a tall order, but L1 userspace running against KVM can
definitely get bad state into the vCPU by abusing KVM ioctls.  So not a VM-to-host
DoS, but still an unprivileged DoS (given that /dev/kvm isn't usually locked down
by default).  Of course that would still require L0 KVM to have a missing check,
or require L1 KVM to be buggy and let userspace modify vTPR.

> 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?

Probably.

> (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."

Eh, not sure if that matters in practice though.

> If KVM is missing any of these checks, then it has an "internal error."

I agree, but KVM has historically had a *lot* of those types of internal errors.
Even now I genuinely don't know if we have 100% coverage and accuracy.  I suppose
we could add a cap or quirk the existing behavior, but I'd prefer not to do that,
because odds are good the restore code would eventually bitrot.

I guess I'd be up for having AI audit the checks, and then ripping out
nested_vmx_restore_host_state() in 7.5 in favor of kvm_prepare_emulation_failure_exit().
That change is pretty darn easy, and would likely revert cleanly too if it came
to that.  Sashiko would probably even understand the implications without extra
guidance, i.e. would hopefully flag missed checks as new features are added, so
maybe my maintenance concerns are unfounded.