linux-kernel - Re: [PATCH 0/7] IBRS patch series

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20180105150340.GJ26807@redhat.com>
Date:   Fri, 5 Jan 2018 16:03:40 +0100
From:   Andrea Arcangeli <aarcange@...hat.com>
To:     "Van De Ven, Arjan" <arjan.van.de.ven@...el.com>
Cc:     Linus Torvalds <torvalds@...ux-foundation.org>,
        David Woodhouse <dwmw2@...radead.org>,
        Tim Chen <tim.c.chen@...ux.intel.com>,
        Thomas Gleixner <tglx@...utronix.de>,
        Andy Lutomirski <luto@...nel.org>,
        Greg KH <gregkh@...uxfoundation.org>,
        "Hansen, Dave" <dave.hansen@...el.com>,
        Andi Kleen <ak@...ux.intel.com>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 0/7] IBRS patch series

On Fri, Jan 05, 2018 at 02:52:33PM +0000, Van De Ven, Arjan wrote:
> I'm sorry but your whole statement reeks a little bit of "perfect is the enemy of good"

My point is exactly that this sentences could apply to spectre
variant#2 in the first place..

If we start moving in any direction, either we reach "perfection" or
moving towards perfection and still being in "perfect is the enemy of
good" territory doesn't sound great to me.

The reptoline status with 3 way " IBRS skylake mode" or " 2way
reptoline code emission from gcc for older CPUs or CPUs without
SPEC_CTRL" plus IBRS forced still to be used around all
firmware/bios/SMM (how do you do IBRS on those CPUS without IBRS, that
requires yet another IBPB alternative combined with AMD reptoline
case) is far from a "less is more" or KISS.

This whole reptoline work is total waste for future silicon so I like
to keep it simple and obviously mathematically safe at the same
time... and also easy to activate for full math safe qemu ibrs 2 mode
without having to do a 2-way reptoline gcc code emission and dynamic
patching on qemu startup.