Messages in this thread | | | Date | Thu, 18 Jan 2018 12:24:31 -0600 | From | Josh Poimboeuf <> | Subject | Re: [PATCH 23/35] x86/speculation: Add basic speculation control code |
| |
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
| |