linux-kernel - Re: [PATCH RFC 1/2] KVM: TDX: Disable general support for MWAIT in guest

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <136ab62e9f403ad50a7c2cb4f9196153a0a2ef7c.camel@intel.com>
Date: Mon, 18 Aug 2025 18:49:42 +0000
From: "Edgecombe, Rick P" <rick.p.edgecombe@...el.com>
To: "Hunter, Adrian" <adrian.hunter@...el.com>, "seanjc@...gle.com"
	<seanjc@...gle.com>
CC: "Gao, Chao" <chao.gao@...el.com>, "Huang, Kai" <kai.huang@...el.com>,
	"binbin.wu@...ux.intel.com" <binbin.wu@...ux.intel.com>, "Chatre, Reinette"
	<reinette.chatre@...el.com>, "Li, Xiaoyao" <xiaoyao.li@...el.com>,
	"kirill.shutemov@...ux.intel.com" <kirill.shutemov@...ux.intel.com>,
	"tony.lindgren@...ux.intel.com" <tony.lindgren@...ux.intel.com>,
	"kvm@...r.kernel.org" <kvm@...r.kernel.org>, "pbonzini@...hat.com"
	<pbonzini@...hat.com>, "Yamahata, Isaku" <isaku.yamahata@...el.com>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>, "Zhao, Yan Y"
	<yan.y.zhao@...el.com>, "Weiny, Ira" <ira.weiny@...el.com>
Subject: Re: [PATCH RFC 1/2] KVM: TDX: Disable general support for MWAIT in
 guest

Attn: Binbin, Xiaoyao

On Mon, 2025-08-18 at 07:05 -0700, Sean Christopherson wrote:
> NAK.
> 
> Fix the guest, or wherever else in the pile there are issues.  KVM is NOT carrying
> hack-a-fixes to workaround buggy software/firmware.  Been there, done that.

Yes, I would have thought we should have at least had a TDX module change option
for this.

But side topic. We have an existing arch TODO around creating some guidelines
around how CPUID bit configuration should evolve.

A new directly configurable CPUID bit that affects host state is an obvious no-
no. But how about a directly configurable bit that can't hurt the host, but
requires host changes to virtualize in an x86 arch compliant way? (not quite
like this MWAIT case)

In some ways KVM shouldn't care since it's between userspace and the TDX module.
But userspace may try to set it and then we would have a situation where the bit
would remain malfunctioning until/if KVM decided to add support for the bit. If
KVM never did then it would be silently broken. It's not a kernel regression,
but not great either.

If we required some other opt-in for each such feature, it would further
complicate the CPUID bit configuration interface. I think I'd rather keep
directly configurable CPUID bits as the main way to configure the TD.

Maybe we could have the TDX module enumerate which direct bits require VMM
enabling and KVM could automatically filter them? So then TDX module could add
simple feature bits without fuss, but KVM could manually enable the bits that
require consideration.