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: <1515166704.29312.140.camel@infradead.org>
Date:   Fri, 05 Jan 2018 15:38:24 +0000
From:   David Woodhouse <dwmw2@...radead.org>
To:     "Van De Ven, Arjan" <arjan.van.de.ven@...el.com>,
        Paul Turner <pjt@...gle.com>,
        Linus Torvalds <torvalds@...ux-foundation.org>
Cc:     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>,
        Andrea Arcangeli <aarcange@...hat.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, 2018-01-05 at 14:42 +0000, Van De Ven, Arjan wrote:

> This is why I said I would like to see retpoline be the default, with
> IBRS an opt-in for the paranoid. I guess David will turn that on ;-)

I can live with that.

It really depends how you look at it.

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".

Retpoline is sufficient on pre-Skylake. On Skylake... it's complicated,
and that's why my default position has always been that we should
prefer IBRS there. Especially as it isn't *even* as much of a
performance win there.

But you're right, the holes that it opens up when compared to IBRS are
minimal, and it *is* still a performance win (just less so than on
earlier CPUs). So if your recommendation is that we stick with
retpoline until IBRS_ATT comes along, I can live with that. People
always have the option to build without retpoline, and then they get to
use IBRS in the kernel if they want.

Download attachment "smime.p7s" of type "application/x-pkcs7-signature" (5213 bytes)