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: <cf85f4fbf1339ea998fa34e722d2bac9ebced05b.camel@intel.com>
Date: Wed, 14 Aug 2024 17:17:31 +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 Wed, 2024-08-14 at 19:36 +0800, Chao Gao wrote:
> > 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.
> 
> I don't fully understand "getting boxed into some ABI". But filtering out
> unsupported bits could also cause ABI breakage if those bits later become
> supported and are no longer filtered, but userspace may still expect them to
> be
> cleared.

Hmm, any change to the kernel could cause a backwards compatibility issue. But
if KVM doesn't support the bit, I would hope userspace wouldn't have developed
some problematic behavior around it already.

I guess the problem would be if, as is currently implemented in the QEMU
patches, userspace checks for unexpected bits and errors out. This would fail
similarly if the bits were not filtered by KVM and TDX module was updated to a
version with new fixed bits, so it kind of leads you down the road to "fixed
bits are a problem", doesn't it?

> 
> It seems that KVM would have to refuse to work with the TDX module if it
> detects some fixed-1/native bits are unsupported/unknown.

I don't think there is really a way to detect this, without encoding a bunch of
CPUID rules into KVM.

> 
> But if we do that, IIUC, disabling certain features using the "clearcpuid="
> kernel cmdline on the host may cause KVM to be incompatible with the TDX
> module. Anyway, this is probably a minor issue.

True, I would think that would be out of scope for backwards compatibility
though.