On Thu, Jan 18, 2018 at 06:12:36PM +0100, Paolo Bonzini wrote: > On 18/01/2018 18:08, Dave Hansen wrote: > > On 01/18/2018 08:37 AM, Josh Poimboeuf wrote: > >>> > >>> --- a/Documentation/admin-guide/kernel-parameters.txt > >>> +++ b/Documentation/admin-guide/kernel-parameters.txt > >>> @@ -3932,6 +3932,7 @@ > >>> retpoline - replace indirect branches > >>> retpoline,generic - google's original retpoline > >>> retpoline,amd - AMD-specific minimal thunk > >>> + ibrs - Intel: Indirect Branch Restricted > >>> Speculation > >> Are there plans to add spectre_v2=ibrs_always to prevent SMT-based > >> attacks? > > > > What does "ibrs_always" mean to you?
Maybe ibrs_always isn't the best name. Basically we need an option to protect user-user attacks via SMT. It could be implemented with IBRS=1, or STIBP, or as part of the mythical IBRS_ATT. Maybe a 'user_smt' option, which could be appended to existing 'retpoline' or 'ibrs' options? Like spectre_v2=retpoline,user_smt or spectre_v2=ibrs,user_smt? > > There is a second bit in the MSR (STIBP) that is intended to keep > > hyperthreads from influencing each-other. That is behavior is implicit > > when IBRS is enabled. Does this bit exist yet? I've never seen any patches for it. > Yeah, I think we should have a mode to always leave that enabled, or > always set IBRS=1. > > > I think ibrs_always *should* probably be kept to refer to the future > > CPUs that can safely leave IBRS enabled all the time. > > Is that "safely" or "without throwing performance down the drain"? > > Does "always IBRS=1" *hinder* the mitigation on existing processor, as > long as you reset IBRS=1 on kernel entry and vmexit? Or is it just slow? Yes, enquiring minds want to know... -- Josh
