linux-kernel - RE: [patch RFC 5/5] 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]

Message-ID: <0575AF4FD06DD142AD198903C74E1CC87A572336@ORSMSX103.amr.corp.intel.com>
Date:   Wed, 10 Jan 2018 13:45:52 +0000
From:   "Van De Ven, Arjan" <arjan.van.de.ven@...el.com>
To:     David Woodhouse <dwmw2@...radead.org>,
        Andrea Arcangeli <aarcange@...hat.com>,
        Jiri Kosina <jikos@...nel.org>,
        "Mallick, Asit K" <asit.k.mallick@...el.com>
CC:     Peter Zijlstra <peterz@...radead.org>,
        "Hansen, Dave" <dave.hansen@...el.com>,
        Thomas Gleixner <tglx@...utronix.de>,
        LKML <linux-kernel@...r.kernel.org>,
        Linus Torvalds <torvalds@...uxfoundation.org>,
        "x86@...nel.org" <x86@...nel.org>,
        "Borislav Petkov" <bp@...en8.de>,
        Tim Chen <tim.c.chen@...ux.intel.com>,
        Andi Kleen <ak@...ux.intel.com>,
        Greg KH <gregkh@...uxfoundation.org>,
        Andy Lutomirski <luto@...nel.org>
Subject: RE: [patch RFC 5/5] x86/speculation: Add basic speculation control
 code

 
> Andrea, what you're saying is directly contradicting what I've heard
> from Intel.
> 
> The documentation already distinguishes between IBRS on current
> hardware, and IBRS_ATT on future hardware. If it was the case that IBRS
> on current hardware is a set-and-forget option and completely disables
> branch prediction, then they would say that. Rather than explicitly
> saying the *opposite*, specifically for the case of current hardware,
> as they do.
> 
> Rather than continuing to debate it, perhaps it's best just to wake for
> the US to wake up, and Intel to give a definitive answer.

On current hardware, you cannot just set IBRS always.


(In practice, on some you might get lucky if you try. Intel does not guarantee it. Intel does not test it. The model is to write the msr on privilege change, e.g. ring transition)