linux-kernel - Re: [PATCH 25/25] KVM: x86: Add CPUID bits missing from KVM_GET_SUPPORTED

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: <a24f20625203465b54f20d1fc1456a779eee06a1.camel@intel.com>
Date: Tue, 13 Aug 2024 18:45:50 +0000
From: "Edgecombe, Rick P" <rick.p.edgecombe@...el.com>
To: "Gao, Chao" <chao.gao@...el.com>
CC: "seanjc@...gle.com" <seanjc@...gle.com>, "Huang, Kai"
	<kai.huang@...el.com>, "Li, Xiaoyao" <xiaoyao.li@...el.com>,
	"isaku.yamahata@...il.com" <isaku.yamahata@...il.com>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"tony.lindgren@...ux.intel.com" <tony.lindgren@...ux.intel.com>,
	"kvm@...r.kernel.org" <kvm@...r.kernel.org>, "pbonzini@...hat.com"
	<pbonzini@...hat.com>
Subject: Re: [PATCH 25/25] KVM: x86: Add CPUID bits missing from
 KVM_GET_SUPPORTED_CPUID

On Tue, 2024-08-13 at 19:34 +0800, Chao Gao wrote:
> Mandating that all fixed-1 bits be supported by KVM would be a burden for both
> KVM and the TDX module: the TDX module couldn't add any fixed-1 bits until KVM
> supports them, and 

> KVM shouldn't drop any feature that was ever a fixed-1 bit
> in any TDX module.

Honest question...can/does this happen for normal VMs? KVM dropping support for
features? I think I recall even MPX getting limped along for backward
compatibility reasons.

>  I don't think this is a good idea. TDX module support for a
> feature will likely be ready earlier than KVM's, as TDX module is smaller and
> is developed inside Intel. Requiring the TDX module to avoid adding fixed-1
> bits doesn't make much sense, as making all features configurable would
> increase its complexity.
> 
> I think adding new fixed-1 bits is fine as long as they don't break KVM, i.e.,
> KVM shouldn't need to take any action for the new fixed-1 bits, like
> saving/restoring more host CPU states across TD-enter/exit or emulating
> CPUID/MSR accesses from guests

If these would only be simple features, then I'd wonder how much complexity
making them configurable would really add to the TDX module.

I think there are more concerns than just TDX module breaking KVM. (my 2 cents
would be that it should just be considered a TDX module bug) But KVM should also
want to avoid getting boxed into some ABI. For example a a new userspace
developed against a new TDX module, but old KVM could start using some new
feature that KVM would want to handle differently. As you point out KVM
implementation could happen later, at which point userspace could already expect
a certain behavior. Then KVM would have to have some other opt in for it's
preferred behavior.

Now, that is comparing *sometimes* KVM needing to have an opt-in, with TDX
module *always* needing an opt-in. But I don't see how never having fixed bits
is more complex for KVM.