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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20181119231649.GI29258@redhat.com>
Date:   Mon, 19 Nov 2018 18:16:49 -0500
From:   Andrea Arcangeli <aarcange@...hat.com>
To:     Dave Hansen <dave.hansen@...el.com>
Cc:     Jiri Kosina <jikos@...nel.org>,
        Thomas Gleixner <tglx@...utronix.de>,
        Tim Chen <tim.c.chen@...ux.intel.com>,
        Tom Lendacky <thomas.lendacky@....com>,
        Ingo Molnar <mingo@...hat.com>,
        Peter Zijlstra <peterz@...radead.org>,
        Josh Poimboeuf <jpoimboe@...hat.com>,
        David Woodhouse <dwmw@...zon.co.uk>,
        Andi Kleen <ak@...ux.intel.com>,
        Casey Schaufler <casey.schaufler@...el.com>,
        Asit Mallick <asit.k.mallick@...el.com>,
        Arjan van de Ven <arjan@...ux.intel.com>,
        Jon Masters <jcm@...hat.com>,
        Waiman Long <longman9394@...il.com>,
        LKML <linux-kernel@...r.kernel.org>, x86@...nel.org,
        Willy Tarreau <w@....eu>
Subject: Re: [Patch v5 11/16] x86/speculation: Add Spectre v2 app to app
 protection modes

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