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]

Date:   Fri, 5 Jan 2018 04:09:33 -0800
From:   Paul Turner <pjt@...gle.com>
To:     Paolo Bonzini <pbonzini@...hat.com>
Cc:     "Van De Ven, Arjan" <arjan.van.de.ven@...el.com>,
        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>,
        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, Jan 5, 2018 at 3:32 AM, Paolo Bonzini <pbonzini@...hat.com> wrote:
> On 04/01/2018 22:22, Van De Ven, Arjan wrote:
>> this is about a level of paranoia you are comfortable with.
>>
>> Retpoline on Skylake raises the bar for the issue enormously, but
>> there are a set of corner cases that exist and that are not trivial
>> to prove you dealt with them.
>>
>> personally I am comfortable with retpoline on Skylake, but I would
>> like to have IBRS as an opt in for the paranoid.
>>
>
> IBRS actually seems to perform more than decently on Skylake with the
> microcode updates we're shipping in RHEL---much more so than Broadwell
> or Haswell.  Can you confirm that this is expected?
>

The cost of IBRS performance varies with processor generation.
Skylake incurs the least overhead.  It is expected that future
generations will be better still.

There are two distinct costs: The overhead to an indirect branch, and
the transition cost for enabling/disabling the feature as we schedule
into (and out of) protected code.

A naked indirect call (with IBRS enabled) on Skylake and a retpolined
call have approximately the same cost.
(I have not compared this cost for pre-Skylake uarchs.)

The main difference is that a retpolined binary does not incur the
transition costs, nor does it interact with sibling execution while
protected code is running.

A trade-off to consider when choosing between them is that it does on
the other hand carry a higher implementation (versus run-time) cost.
As Arjan references above, this is also a sliding scale.  The bar is
significantly raised by compiling with retpoline alone, and the
vulnerability is wholly eliminated if the preconditions are also
satisfied.
(And obviously, if you do not have the sources to the target you are
trying to protect, IBRS allows you to run it in a protected fashion --
while it cannot easily be retpolined.)