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]
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)

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ