linux-kernel - RE: [PATCH 23/35] x86/speculation: Add basic speculation control code

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]

Date:   Fri, 19 Jan 2018 04:15:33 +0000
From:   "Van De Ven, Arjan" <arjan.van.de.ven@...el.com>
To:     Andy Lutomirski <luto@...nel.org>,
        Andrea Arcangeli <aarcange@...hat.com>
CC:     Josh Poimboeuf <jpoimboe@...hat.com>,
        Paolo Bonzini <pbonzini@...hat.com>,
        "Hansen, Dave" <dave.hansen@...el.com>,
        Peter Zijlstra <peterz@...radead.org>,
        David Woodhouse <dwmw2@...radead.org>,
        "Thomas Gleixner" <tglx@...utronix.de>,
        LKML <linux-kernel@...r.kernel.org>,
        "Raj, Ashok" <ashok.raj@...el.com>,
        Tim Chen <tim.c.chen@...ux.intel.com>,
        "Linus Torvalds" <torvalds@...ux-foundation.org>,
        Greg KH <gregkh@...uxfoundation.org>,
        Andi Kleen <ak@...ux.intel.com>,
        "Williams, Dan J" <dan.j.williams@...el.com>,
        "Nakajima, Jun" <jun.nakajima@...el.com>,
        "Mallick, Asit K" <asit.k.mallick@...el.com>,
        Jason Baron <jbaron@...mai.com>
Subject: RE: [PATCH 23/35] x86/speculation: Add basic speculation control
 code

> Enabling IBRS does not prevent software from controlling the predicted
> targets of indirect branches of unrelated software executed later at
> the same predictor mode (for example, between two different user
> applications, or two different virtual machines). Such isolation can
> be ensured through use of the IBPB command, described in Section
> 2.5.3, “Indirect Branch Predictor Barrier (IBPB)”.
> 
> So maybe it's poorly written, but I see nothing in that language that
> suggests that IBRS=1 (on a CPU without enhanced IBRS) provides any
> guarantees at all about who can or cannot control speculation of
> indirect branches in user mode.

there is no such guarantee. Some of the IBRS implementations will actually flush rather than disable, or flush parts and disable other parts.

yes the wording is a bit cryptic, but it's also very explicit about what it covers (and the rest is not covered!) and had to allow a few different implementations unfortunately.