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

On Wed, 2024-08-14 at 06:35 -0700, Sean Christopherson wrote:
> > One scenario where "fixed-1" bits can help is: we discover a security issue
> > and
> > release a microcode update to expose a feature indicating which CPUs are
> > vulnerable. if the TDX module allows the VMM to configure the feature as 0
> > (i.e., not vulnerable) on vulnerable CPUs, a TD might incorrectly assume
> > it's
> > not vulnerable, creating a security issue.
> > 
> > I think in above case, the TDX module has to add a "fixed-1" bit. An example
> > of
> > such a feature is RRSBA in the IA32_ARCH_CAPABILITIES MSR.
> 
> That would be fine, I would classify that as reasonable.  However, that
> scenario
> doesn't really work in practice, at least not the way Intel probably hopes it
> plays out.  For the new fixed-1 bit to provide value, it would require a guest
> reboot and likely a guets kernel upgrade.

If we allow "reasonable" fixed bits, we need to decide how to handle any that
KVM sees but doesn't know about. Not filtering them is simpler to implement.
Filtering them seems a little more controlled to me.

It might depend on how reasonable, "reasonable" turns out. Maybe we give not
filtering a try and see how it goes. If we run into a problem, we can filter new
bits from that point, and add a quirk for whatever the issue is. I'm still on
the fence.