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]

Message-ID: <CA+55aFzNQ8CZ8iNcPXrCfyk=1edMiRGDA0fY0rd87BsFKBxgAw@mail.gmail.com>
Date:   Thu, 11 Jan 2018 17:19:51 -0800
From:   Linus Torvalds <torvalds@...ux-foundation.org>
To:     Dan Williams <dan.j.williams@...el.com>
Cc:     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, 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 Thu, Jan 11, 2018 at 4:46 PM, Dan Williams <dan.j.williams@...el.com> wrote:
>
> This series incorporates Mark Rutland's latest ARM changes and adds
> the x86 specific implementation of 'ifence_array_ptr'. That ifence
> based approach is provided as an opt-in fallback, but the default
> mitigation, '__array_ptr', uses a 'mask' approach that removes
> conditional branches instructions, and otherwise aims to redirect
> speculation to use a NULL pointer rather than a user controlled value.

Do you have any performance numbers and perhaps example code
generation? Is this noticeable? Are there any microbenchmarks showing
the difference between lfence use and the masking model?

Having both seems good for testing, but wouldn't we want to pick one in the end?

Also, I do think that there is one particular array load that would
seem to be pretty obvious: the system call function pointer array.

Yes, yes, the actual call is now behind a retpoline, but that protects
against a speculative BTB access, it's not obvious that it  protects
against the mispredict of the __NR_syscall_max comparison in
arch/x86/entry/entry_64.S.

The act of fetching code is a kind of read too. And retpoline protects
against BTB stuffing etc, but what if the _actual_ system call
function address is wrong (due to mis-prediction of the system call
index check)?

Should the array access in entry_SYSCALL_64_fastpath be made to use
the masking approach?

                Linus