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. >From memory, however, the docs were quite clear that setting leaving IBRS set when entering user mode or guest mode does not guarantee any particular protection unless an additional CPUID bit (the name of which I forget) is set, and that current CPUs will *not* get that bit set by microcode update. IOW the protection given is that, if you set IBRS bit zero after entry to kernel mode, you are protected until you re-enter user mode. When you're in user mode, you're not protected. When you return back to kernel mode, you *still* aren't protected no matter what value is in the MSR until you write 1 again. > > That is true no matter if kernel is using retpolines or ibrs. > > IBRS is semantically equivalent to "STIBP; IBPB", so user_ibrs is > always inclusive of user_stibp. Are you quite sure? I had the impression that IBPB was much slower than writing 1 to IBRS and that writing 1 to IBRS has much more limited effects.
