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: <20180110154729.GK9417@redhat.com>
Date:   Wed, 10 Jan 2018 16:47:29 +0100
From:   Andrea Arcangeli <aarcange@...hat.com>
To:     David Woodhouse <dwmw2@...radead.org>
Cc:     Dave Hansen <dave.hansen@...el.com>,
        Thomas Gleixner <tglx@...utronix.de>,
        Jiri Kosina <jikos@...nel.org>,
        "asit.k.mallick" <asit.k.mallick@...el.com>,
        "Van De Ven, Arjan" <arjan.van.de.ven@...el.com>,
        Peter Zijlstra <peterz@...radead.org>,
        LKML <linux-kernel@...r.kernel.org>,
        Linus Torvalds <torvalds@...uxfoundation.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

On Wed, Jan 10, 2018 at 03:24:17PM +0000, David Woodhouse wrote:
> Since it achieves nothing¹ but to make userspace run slower, there's no
> need to write it again on returning to userspace. It will perform that
> function just fine without doing so.

Ok, very glad we are on the same page now.

Note that as far as I can tell there was no way to answer the above
question by reading the spec.

You also explicitly used the word barrier in association with IBRS
before, but there was no word barrier in the aforementioned specs in
association with IBRS (every word barrier was always and only in
association with IBPB).

I hope this discussion helped clear the additional barrier semantics
of IBRS in more understandable way for the current/future upstream
code.

Thanks,
Andrea