[<prev] [next>] [day] [month] [year] [list]
Message-ID: <20250501150323.2242232-1-derkling@google.com>
Date: Thu, 1 May 2025 15:03:23 +0000
From: Patrick Bellasi <derkling@...gle.com>
To: Borislav Petkov <bp@...en8.de>
Cc: Sean Christopherson <seanjc@...gle.com>, Yosry Ahmed <yosry.ahmed@...ux.dev>,
Patrick Bellasi <derkling@...gle.com>, Paolo Bonzini <pbonzini@...hat.com>,
Josh Poimboeuf <jpoimboe@...hat.com>, Pawan Gupta <pawan.kumar.gupta@...ux.intel.com>, x86@...nel.org,
kvm@...r.kernel.org, linux-kernel@...r.kernel.org,
Patrick Bellasi <derkling@...bug.net>, Brendan Jackman <jackmanb@...gle.com>,
David Kaplan <David.Kaplan@....com>, Michael Larabel <Michael@...haellarabel.com>
Subject: Re: x86/bugs: KVM: Add support for SRSO_MSR_FIX, back for moar
> On Wed, Apr 30, 2025 at 04:33:19PM -0700, Sean Christopherson wrote:
> > Eww. That's quite painful, and completely disallowing enable_virt_on_load is
> > undesirable, e.g. for use cases where the host is (almost) exclusively running
> > VMs.
>
> I wanted to stay generic... :-)
>
> > Best idea I have is to throw in the towel on getting fancy, and just maintain a
> > dedicated count in SVM.
> >
> > Alternatively, we could plumb an arch hook into kvm_create_vm() and kvm_destroy_vm()
> > that's called when KVM adds/deletes a VM from vm_list, and key off vm_list being
> > empty. But that adds a lot of boilerplate just to avoid a mutex+count.
>
> FWIW, that was Tom's idea.
FWIW, this could be helpful for ASI as well going forward, i.e. the set of ASI
driven mitigations could be different whether there are VMs on a system or not,
because the attack vectors are different.
So, having a first class and properly defined mechanisms to know if there are
effectively VMs running on a system would be generically convenient.
But maybe that's something we can work on later on?
Best,
Patrick
Powered by blists - more mailing lists