linux-kernel - Re: [PATCH] x86/bugs: KVM: Add support for SRSO_MSR

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <Z5KEoepANyswViO_@google.com>
Date: Thu, 23 Jan 2025 10:04:17 -0800
From: Sean Christopherson <seanjc@...gle.com>
To: Borislav Petkov <bp@...en8.de>
Cc: Borislav Petkov <bp@...nel.org>, X86 ML <x86@...nel.org>, Paolo Bonzini <pbonzini@...hat.com>, 
	Josh Poimboeuf <jpoimboe@...hat.com>, Pawan Gupta <pawan.kumar.gupta@...ux.intel.com>, 
	KVM <kvm@...r.kernel.org>, LKML <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] x86/bugs: KVM: Add support for SRSO_MSR_FIX

On Thu, Jan 23, 2025, Borislav Petkov wrote:
> On Thu, Jan 23, 2025 at 08:25:17AM -0800, Sean Christopherson wrote:
> > But if we wanted to catch all paths, wrap the guts and clear the feature in the
> > outer layer?
> 
> Yap, all valid points, thanks for catching those.
> 
> > +static void __init srso_select_mitigation(void)
> > +{
> > +       __srso_select_mitigation();
> >  
> >         if (srso_mitigation != SRSO_MITIGATION_BP_SPEC_REDUCE)
> >                 setup_clear_cpu_cap(X86_FEATURE_SRSO_BP_SPEC_REDUCE);
> > -
> > -       pr_info("%s\n", srso_strings[srso_mitigation]);
> >  }
> 
> What I'd like, though, here is to not dance around this srso_mitigation
> variable setting in __srso_select_mitigation() and then know that the __
> function did modify it and now we can eval it.
> 
> I'd like for the __ function to return it like __ssb_select_mitigation() does.
> 
> But then if we do that, we'll have to do the same changes and turn the returns
> to "goto out" where all the paths converge. And I'd prefer if those paths
> converged anyway and not have some "early escapes" like those returns which
> I completely overlooked. :-\
> 
> And that code is going to change soon anyway after David's attack vectors
> series.
> 
> So, long story short, I guess the simplest thing to do would be to simply do
> the below.

I almost proposed that as well, the only reason I didn't is because I wasn't sure
what to do with the pr_info() at the end.