netdev - Re: [PATCH v2 00/19] prevent bounds-check bypass via speculative execution

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:   Tue, 16 Jan 2018 11:21:19 -0800
From:   Tony Luck <tony.luck@...il.com>
To:     Linus Torvalds <torvalds@...ux-foundation.org>
Cc:     Dan Williams <dan.j.williams@...el.com>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        Mark Rutland <mark.rutland@....com>,
        kernel-hardening@...ts.openwall.com,
        Peter Zijlstra <peterz@...radead.org>,
        Alan Cox <alan.cox@...el.com>,
        Will Deacon <will.deacon@....com>,
        Alexei Starovoitov <ast@...nel.org>,
        Solomon Peachy <pizza@...ftnet.org>,
        "H. Peter Anvin" <hpa@...or.com>,
        Christian Lamparter <chunkeey@...glemail.com>,
        Elena Reshetova <elena.reshetova@...el.com>,
        "linux-arch@...r.kernel.org" <linux-arch@...r.kernel.org>,
        Andi Kleen <ak@...ux.intel.com>,
        "James E.J. Bottomley" <jejb@...ux.vnet.ibm.com>,
        Linux SCSI List <linux-scsi@...r.kernel.org>,
        Jonathan Corbet <corbet@....net>,
        "the arch/x86 maintainers" <x86@...nel.org>,
        Russell King <linux@...linux.org.uk>,
        Ingo Molnar <mingo@...hat.com>,
        Catalin Marinas <catalin.marinas@....com>,
        Alexey Kuznetsov <kuznet@....inr.ac.ru>,
        Linux Media Mailing List <linux-media@...r.kernel.org>,
        Tom Lendacky <thomas.lendacky@....com>,
        Kees Cook <keescook@...omium.org>, Jan Kara <jack@...e.com>,
        Al Viro <viro@...iv.linux.org.uk>, qla2xxx-upstream@...gic.com,
        Thomas Gleixner <tglx@...utronix.de>,
        Mauro Carvalho Chehab <mchehab@...nel.org>,
        Kalle Valo <kvalo@...eaurora.org>,
        Alan Cox <alan@...ux.intel.com>,
        "Martin K. Petersen" <martin.petersen@...cle.com>,
        Hideaki YOSHIFUJI <yoshfuji@...ux-ipv6.org>,
        Greg KH <gregkh@...uxfoundation.org>,
        Linux Wireless List <linux-wireless@...r.kernel.org>,
        "Eric W. Biederman" <ebiederm@...ssion.com>,
        Network Development <netdev@...r.kernel.org>,
        Andrew Morton <akpm@...ux-foundation.org>,
        "David S. Miller" <davem@...emloft.net>,
        Laurent Pinchart <laurent.pinchart@...asonboard.com>
Subject: Re: [PATCH v2 00/19] prevent bounds-check bypass via speculative execution

On Sat, Jan 13, 2018 at 10:51 AM, Linus Torvalds
<torvalds@...ux-foundation.org> wrote:
> On Fri, Jan 12, 2018 at 4:15 PM, Tony Luck <tony.luck@...il.com> wrote:
> So your argument depends on "the uarch will actually run the code in
> order if there are no events that block the pipeline".

And might be bogus ... I'm a software person not a u-arch expert. That
sounded good in my head, but the level of parallelism may be greater
than I can imagine.

> Or at least it depends on a certain latency of the killing of any OoO
> execution being low enough that the cache access doesn't even begin.
>
> I realize that that is very much a particular microarchitectural
> detail, but it's actually a *big* deal. Do we have a set of rules for
> what is not a worry, simply because the speculated accesses get killed
> early enough?
>
> Apparently "test a register value against a constant" is good enough,
> assuming that register is also needed for the address of the access.

People who do understand this are working on what can be guaranteed.
For now don't make big plans based on my ramblings.

-Tony