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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <20180105160534.GR26807@redhat.com>
Date:   Fri, 5 Jan 2018 17:05:34 +0100
From:   Andrea Arcangeli <aarcange@...hat.com>
To:     David Woodhouse <dwmw2@...radead.org>
Cc:     "Van De Ven, Arjan" <arjan.van.de.ven@...el.com>,
        Paul Turner <pjt@...gle.com>,
        Linus Torvalds <torvalds@...ux-foundation.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 03:38:24PM +0000, David Woodhouse wrote:
> We had IBRS first, and especially on Broadwell and earlier, its
> performance really is painful.
> 
> Then came retpoline, purely as an optimisation. A very *important*
> performance improvement, but an optimisation nonetheless.
>
> When looking at optimisations, it is rare for us to say "oh, well it
> opens up only a *small* theoretical security hole, but it's faster so
> that's OK".

I couldn't express any better than the above, the way I look at
repotlines.

Now seeing how this thing escalates with 2-way gcc code emission with
amd version that will not have ibrs at all to call it around the bios
etc... and IBRS skylake is still needed as a 3-way alternative and no
code exists to even patch it all at boot like that, and then qemu has
to be compiled with reptoline and 2-way alternative there too, to
achieve ibrs 2 ibpb 1, it's not looking like the way to go to me.

Not in the short term at least, and for the long term "reptoline" is
guaranteed a totally useless effort.

reptoline is like highmem kmap() etc... eventually nobody will ever
use reptoline. reptoline is more interesting for downstream in fact if
something where at least we won't have to deal with that forever where
there's more control on the toolchain used, and after a certain number
of years that code expires.

I can imagine we'll unfortunately have to deal with reptoline at some
point, but starting with reptoline at least looks backwards,
especially if it's the long term you're planning for.

Thanks,
Andrea