[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <Zr0gEupQ7-Vsj3di@google.com>
Date: Wed, 14 Aug 2024 14:22:26 -0700
From: Sean Christopherson <seanjc@...gle.com>
To: Rick P Edgecombe <rick.p.edgecombe@...el.com>
Cc: Chao Gao <chao.gao@...el.com>, Xiaoyao Li <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>, Kai Huang <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, Aug 14, 2024, Rick P Edgecombe wrote:
> 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.
As I see it, it's ultimately unlikely to be KVM's problem. If Intel ships a
TDX-Module that does bad things, and someone's setup breaks when they upgrade to
that TDX-Module, then their gripe is with Intel. KVM can't do anything to remedy
the problem.
If the upgrade breaks a setup because it confuses _KVM_, then I'll care, but I
suspect/hope that won't happen in practice, purely because KVM has so little
visiblity into the guest, i.e. doesn't care what is/isn't advertised to the guest.
FWIW, AMD has effectively gone the "fixed-1" route for a few things[*], e.g. KVM
can't intercept XCR0 or XSS writes. And while I detest the behavior, I haven't
refused to merge support for SEV-ES+. I just grumble every time it comes up :-)
[*] https://lore.kernel.org/all/ZUQvNIE9iU5TqJfw@google.com
Powered by blists - more mailing lists