[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <Z7OUZhyPHNtZvwGJ@Asmaa.>
Date: Mon, 17 Feb 2025 11:56:22 -0800
From: Yosry Ahmed <yosry.ahmed@...ux.dev>
To: Borislav Petkov <bp@...en8.de>
Cc: Sean Christopherson <seanjc@...gle.com>,
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>
Subject: Re: Re: Re: Re: [PATCH] x86/bugs: KVM: Add support for SRSO_MSR_FIX
On Mon, Feb 17, 2025 at 05:07:28PM +0100, Borislav Petkov wrote:
> On Sun, Feb 16, 2025 at 09:59:59PM -0800, Yosry Ahmed wrote:
> > If 1-2% is the cost for keeping the MSR enabled at all times, I wonder
> > if we should just do that for simplicitly, and have it its own
> > mitigation option (chosen by the cmdline).
>
> Yes, that's what David and I think we should do initially.
>
> Then we can chase some more involved scheme like setting the bit before the
> first VM runs and then clearing it when the last one exits. I *think* I've
> seen something like that in KVM but I need to stare in detail.
>
> > - Upon return to userspace (similar to your previous proposal). In this
> > case we run userspace with the MSR cleared, and only perform an IBPB
> > in the exit to userspace pace.
>
> You want to IBPB before clearing the MSR as otherwise host kernel will be
> running with the mistrained gunk from the guest.
I meant IBPB + MSR clear before going to userspace, or IBPB + MSR clear
before a context switch.
>
> > Any thoughts?
>
> Yes, let's keep it simple and do anything more involved *only* if it is really
> necessary.
>
> --
> Regards/Gruss,
> Boris.
>
> https://people.kernel.org/tglx/notes-about-netiquette
Powered by blists - more mailing lists