Re: [Patch v5 11/16] x86/speculation: Add Spectre v2 app to app protection modes

[Thomas Gleixner]

On Mon, 19 Nov 2018, Andrea Arcangeli wrote:
> On Mon, Nov 19, 2018 at 01:33:08PM -0800, Dave Hansen wrote:
> > Here's the current description:
> > 
> > > Setting ... STIBP ... on a logical processor prevents the predicted
> > > targets of indirect branches on any logical processor of that core
>                                     ^^^
> > > from being controlled by software that executes (or executed
> > > previously) on another logical processor of the same core.
>                    ^^^^^^^
> > 
> > 1.
> > https://software.intel.com/security-software-guidance/insights/deep-dive-single-thread-indirect-branch-predictors
> 
> I'm not used to official specs in a "insight & deep dive"
> blog-post-like webpage, so I didn't notice this deep dive detail.

But you might have noticed the wording in:

  Speculative Execution Side Channel Mitigations
  Revision 2.0
  May 2018

which says:

  Setting bit 1 (STIBP) of the IA32_SPEC_CTRL MSR on a logical processor
  prevents the predicted targets of indirect branches on any logical
  processor of that core from being controlled by software that executes (or
  executed previously) on another logical processor of the same core.

i.e. exactly what Dave quoted from the deep dive thingy.

> You use "any" vs "any" but the spec you quoted still says "any" vs
> "another".
>
> If I shall take the above literally it still means that if I set STIBP
> inside SECCOMP, as long as it's set, it prevents indirect branches of
> all siblings to be controlled from code outside the SECCOMP jail
> running in another sibling (or that run previously in another
> sibling). I.e. the "deep dive" stronger semantics of STIBP just mean
> the code outside SECCOMP cannot attack itself while the code inside
> SECCOMP runs and keeps STIBP set.

The point is that when you enable STIBP on any sibling then all siblings of
the same core are protected against each other simply because the predictor
is shared. Otherwise you would hardly have sibling to sibling influence.

Yes, I agree the documentation is lousy, but I also agree with the
interpretation from Dave, Andi and Tim.

> If this is clarified the concern that remains is that lots of
> potentially performance critical stuff runs under SECCOMP but of
> course it changes everything in terms of possibly enabling STIBP under
> SECCOMP by default, it certainly would make more sense then.

Right. If this holds, which I assume, then enabling it for seccomp tasks
would make sense.

Thanks,

	tglx