Re: [PATCH] x86/bugs: KVM: Add support for SRSO_MSR_FIX

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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.




[Index of Archives]     [KVM ARM]     [KVM ia64]     [KVM ppc]     [Virtualization Tools]     [Spice Development]     [Libvirt]     [Libvirt Users]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite Questions]     [Linux Kernel]     [Linux SCSI]     [XFree86]

  Powered by Linux