On 18/01/2018 23:25, Andy Lutomirski wrote: > On Thu, Jan 18, 2018 at 11:08 AM, Andrea Arcangeli <aarca...@redhat.com> > wrote: >> On Thu, Jan 18, 2018 at 12:24:31PM -0600, Josh Poimboeuf wrote: >>> 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. >> User stibp or user ibrs would be different things, both would be valid >> for different use cases, and the user stibp should perform better. >> >> Leaving ibrs on when returning from kernel to userland (or setting >> ibrs if kernel used retpolines instead of ibrs) achieves stronger >> semantics than just setting SPEC_CTRL with stibp when returning to >> userland. > I read the whitepaper that documented the new MSRs a couple days ago > and I'm now completely unable to find it. If anyone could send the > link, that would be great.
https://software.intel.com/sites/default/files/managed/c5/63/336996-Speculative-Execution-Side-Channel-Mitigations.pdf ~Andrew
