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

[Andrea Arcangeli]

On Mon, Nov 19, 2018 at 01:33:08PM -0800, Dave Hansen wrote:
> On 11/19/18 11:32 AM, Andrea Arcangeli wrote:
> > The specs don't say if by making it immune from BTB mistraining, it
> > also could prevent to mistrain the BTB in order to attack what's
> > outside the SECCOMP jail. Probably it won't and I doubt we can rely on
> > it even if some implementation could do that.
> 
> I just talked with Andi and Tim about this.  The *current* spec for
> STIBP[1] states that it bidirectional: setting it on one thread provides
> mitigation against any threads attacking any other thread on the core.
                     ^^^                   ^^^
> 
> This means that it provides protection for victims being in and out of
> SECCOMP jail when the attacker is either in or out of SECCOMP jail.
> 
> However, the current spec[1], differs from the *original* spec PDF that
> Intel released last year.  Both are correct in that they describe all
> current (Intel) implementations of STIBP.  However, the new
> _description_ of STIBP is stronger than it was originally.
> 
> 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.

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.

So you may want to ask why it wasn't written as your "any" vs "any" email:

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 any logical processor of the same core.

A s/another/any/ is still missing to match your exact interpretation,
otherwise it still seems a gray area and I've no idea why it wasn't
written as "any" which would clear any risk for misunderstanding and
instead it kind of uses a word that matches the somewhat more strict
pdf specs.

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.

Thanks,
Andrea