Re: [RFC PATCH 00/27] KVM: x86: Add a paranoid mode for CPUID verification

[Sean Christopherson <seanjc@google.com>]

On Mon, May 18, 2026, Binbin Wu wrote:
> On 5/15/2026 4:08 PM, Xiaoyao Li wrote:
> > On 4/17/2026 3:35 PM, Binbin Wu wrote:
> >> Hi,
> >>
> >> This RFC series is to allow public capture of feedback from TDX
> >> developers before we have too much internal conversations on it and to
> >> initiate code review of Sashiko. It is not yet intended for review by
> >> KVM maintainers. Sean and Paolo, please feel free to ignore this version.
> >>
> >> Originally, we had issues on TDX when a new hardware feature, which is a
> >> host state clobbering feature, is supported by new TDX modules/platforms.
> >> A host state clobbering feature requires KVM to save and restore the
> >> feature's related MSR(s) on host/guest transitions; otherwise, if the
> >> feature is used by TDs, the host state will be corrupted, leading to
> >> unexpected behavior on the host.
> >>
> >> Currently KVM hardcodes a deny list for unsupported host clobbering
> >> features for TDX, i.e. HLE, RTM and WAITPKG. However, KVM can't keep a
> >> list of bits that it may not know about (e.g. the upcoming FRED support
> >> in TDX).
> >>
> >> We had been working internally to propose a TDX specific solution to
> >> solve the host state clobbering feature issue. But during a PUCK meeting,
> >> Sean mentioned that KVM had a more permissive CPUID configuration
> >> interface than desired and there were problems due to it in the past for
> >> normal VMs as well. 
> > 
> > It will be better if some detailed example of problems on normal VMs can be
> > provided.
> 
> Sean mentioned it in PUCK meeting that google internally had some issues before,
> but he didn't tell the details.

For far too long, our VMM didn't sanity check the vCPU model being presented to
the guest against KVM_GET_SUPPORTED_CPUID2.  That's what I'm envisioning for KVM:
something akin to QEMU's default behavior, where QEMU refuses to create a VM if
the user enables unsupported features, unless the users also enables the "let me
shoot myself in the foot" flag.

> >> Sean suggested that KVM should introduce a more
> >> paranoid mode to check CPUID from userspace for VMs in general, as well
> >> as an opt-in interface for userspace. And TDX should use the
> >> infrastructure to enforce paranoid mode non-optionally.
> >>
> >> This RFC patch series adds a paranoid CPUID verification mode for KVM on>
> >> x86, where KVM must be explicitly aware of every CPUID feature exposed to
> >> the guest. When the CPUID paranoid mode is opted-in by userspace or
> >> enforced, KVM will reject any unknown or unsupported feature from
> >> userspace. And it starts to enforce paranoid CPUID verification for TDX.
> > 
> > Regarding the opt-in interface (for normal VMs), I want to know what the
> > benefit it brings for normal VMs when it's opted-in.

More or less the same benefits QEMU's default behavior provides.  Whether or not
the value added, relative to what userspace can/does do, is worth the complexity?
Dunno.  I haven't looked through the series, but this:

  15 files changed, 1298 insertions(+), 525 deletions(-)

definitely gives me pause.

> > If it can make the host more robust or prevent potential attack from
> > malicious userspace + guest, then it should certainly be forced on instead
> > of userspace to opt-in.
> > 
> > If no good benefit, I doubt any userspace will opt it in. E.g, I can see
> > one benefit without the paranoid mode: Userspace can expose the new simple
> > x86 Instruction to guest before KVM supports it by adding one line of
> > F(xxx) in kvm_initialize_cpu_caps()
> > 
> 
> As Rick replied, Sean thought for normal VMs, it could be opted-in to do debug
> or even make it enabled by default.

I doubt we'll ever enabled it by default.  I can see us providing a module param,
so that a deployment can effectively enable it by default, but truly enabling it
by default in KVM will likely never happen.