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. 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. Said that the CPU should better achieve such semantics without really internally issuing an IBPB of course, but you can think at the current IBRS as "STIBP; IBPB". That IBPB immediately after the STIBP makes a difference to the non HT attacks possible on host userland. user_smt wouldn't solve all cases that user_ibrs solves, but it'd be ideal if critical user apps are built with retpolines and the only concern left is a HT/SMT attack on those only need to care about HT/SMT. To begin with, user_ibrs would be more important than user_stibp. On a side note: stibp isn't always available, it requires a new cpuid check on bit 27 too, you can still write to it but it won't #gp, on some CPUs it's simply implicit and you can write to it, but it's a noop. I haven't figured exactly to differentiate when it's disabled or implicitly enabled when not enumerated in cpuid.
