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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <b7ee32f9e343a10094b21bed455262fecd2e071e.camel@intel.com>
Date: Tue, 19 Aug 2025 15:59:44 +0000
From: "Edgecombe, Rick P" <rick.p.edgecombe@...el.com>
To: "Hunter, Adrian" <adrian.hunter@...el.com>, "seanjc@...gle.com"
	<seanjc@...gle.com>, "binbin.wu@...ux.intel.com" <binbin.wu@...ux.intel.com>
CC: "Gao, Chao" <chao.gao@...el.com>, "Huang, Kai" <kai.huang@...el.com>, "Li,
 Xiaoyao" <xiaoyao.li@...el.com>, "Chatre, Reinette"
	<reinette.chatre@...el.com>, "kirill.shutemov@...ux.intel.com"
	<kirill.shutemov@...ux.intel.com>, "tony.lindgren@...ux.intel.com"
	<tony.lindgren@...ux.intel.com>, "pbonzini@...hat.com" <pbonzini@...hat.com>,
	"kvm@...r.kernel.org" <kvm@...r.kernel.org>, "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

On Tue, 2025-08-19 at 13:40 +0800, Binbin Wu wrote:
> Currently, KVM TDX code filters out TSX (HLE or RTM) and WAITPKG using
> tdx_clear_unsupported_cpuid(), which is sort of blacklist.
> 
> I am wondering if we could add another array, e.g., tdx_cpu_caps[], which is the
> TDX version of kvm_cpu_caps[].
> 
> Using tdx_cpu_caps[] is a whitelist way.

We had something like this in some of the earlier revisions of the TDX CPUID
configuration.

> For a new feature
> - If the developer doesn't know anything about TDX, the bit just be added to
>    kvm_cpu_caps[].
> - If the developer knows that the feature supported by both non-TDX VMs and TDs
>    (either the feature doesn't require any additional virtualization support or
>    the virtualization support is added for TDX), extend the macros to set the bit
>    both in kvm_cpu_caps[] and tdx_cpu_caps[].
> - If there is a feature not supported by non-TDX VMs, but supported by TDs,
>    extend the macros to set the bit only in tdx_cpu_caps[].
> So, tdx_cpu_caps[] could be used as the filter of configurable bits reported
> to userspace.

In some ways this is the simplest, but having to maintain a big list in KVM was
not ideal. The original solution started with KVM_GET_SUPPORTED_CPUID and then
massaged the results to fit, so maybe just encoding the whole thing separately
is enough to reconsider it.

But what I was thinking is that we could most of that hardcoded list into the
TDX module, and only keep a list of non-trivial features (i.e. not simple
instruction CPUID bits) in KVM. The list of simple features (definition TBD)
could be provided by the TDX module. So KVM could do the full filtering but only
keep a list that today would just look like TSX and WAITPKG that we already
have. So basically the same as what you are proposing, but just shrinks the size
of list KVM has to keep.

> 
> Comparing to blacklist (i.e., tdx_clear_unsupported_cpuid()), there is no risk
> that a feature not supported by TDX is forgotten to be added to the blacklist.
> Also, tdx_cpu_caps[] could support a feature that not supported for non-TDX VMs.

We definitely can't have TDX module adding any host affecting features that we
would automatically allow. And having a separate opt-in interface that doesn't
"speak" cpuid bits is going to just complicate the already complicated logic
that is in QEMU.

> 
> Then we don't need a host opt-in for these directly configurable bits not
> clobbering host states.
> 
> Of course, to prevent userspace from setting feature bit that would clobber host
> state, but not included in tdx_cpu_caps[], I think a new feature that would
> clobber host state should requires a host opt-in to TDX module.

Yes, but if have some way to get the host clobbering type info programatically
we could keep the host opt-in as part of the main CPUID bit configuration. What
I think will be bad is if we grow a separate protocol of opt-ins. KVM and QEMU
manage everything with CPUID, so it will be easier if we stick to that.