linux-kernel - Re: Avoid speculative indirect calls in kernel

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:   Thu, 4 Jan 2018 14:51:13 +0000
From:   Andrew Cooper <andrew.cooper3@...rix.com>
To:     Paolo Bonzini <pbonzini@...hat.com>,
        "Woodhouse, David" <dwmw@...zon.co.uk>,
        "pavel@....cz" <pavel@....cz>
CC:     "tim.c.chen@...ux.intel.com" <tim.c.chen@...ux.intel.com>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "torvalds@...ux-foundation.org" <torvalds@...ux-foundation.org>,
        "tglx@...utronix.de" <tglx@...utronix.de>,
        "andi@...stfloor.org" <andi@...stfloor.org>,
        "gnomes@...rguk.ukuu.org.uk" <gnomes@...rguk.ukuu.org.uk>,
        "dave.hansen@...el.com" <dave.hansen@...el.com>,
        "gregkh@...ux-foundation.org" <gregkh@...ux-foundation.org>,
        Andrea Arcangeli <aarcange@...hat.com>
Subject: Re: Avoid speculative indirect calls in kernel

On 04/01/18 14:20, Paolo Bonzini wrote:
> On 04/01/2018 12:47, Woodhouse, David wrote:
>> On Thu, 2018-01-04 at 12:42 +0100, Pavel Machek wrote:
>>>> No, really. The full mitigation with the microcode update and IBRS
>>>> support is *slow*. Horribly slow.
>>> What is IBRS? Invalidate BRanch prediction bufferS?
>> That isn't the precise acronym, but yes.
> My stab at backronyming it was "indirect branch restricted speculation",
> and there's also IBPB which is "indirect branch prediction barrier".
>
>> The branch predictor flush that, without retpoline, we have to do on
>> every entry to the kernel. Requires new microcode, and the patches that
>> I believe Intel are *about* to post...
> Based on our experiments it was actually pretty good on Skylake, and bad
> to horrible on earlier machines.  Still, microbenchmarks were in the
> same ballpark as PTI.
>
> BTW, the choices we have implemented in RHEL are basically:
>
> * do nothing
>
> * turn off indirect branch prediction in kernel mode (IBRS=1 in ring 0)
>
> * completely turn off indirect branch prediction (IBRS=1 always, which
> would also let future CPUs do their thing), which can be good for
> paranoia but also for performance in some worklods
>
> * never turn off indirect branch prediction, but use a branch prediction
> barrier on every mode switch (needed for current AMD microcode)

Where have you got this idea from?  Using IBPB on every mode switch
would be an insane overhead to take, and isn't necessary.

Also, remember that PTI and these mitigations are for orthogonal issues.

Perhaps it is easiest to refer directly to the Xen SP2 mitigations and
my commentary of what is going on:
http://xenbits.xen.org/gitweb/?p=people/andrewcoop/xen.git;a=blob;f=xen/arch/x86/spec_ctrl.c;h=79aedf774a390293dfd564ce978500085344e305;hb=refs/heads/sp2-mitigations-v6.5#l192

With the GCC -mindirect-branch=thunk-external support, and microcode,
Xen will make a boot-time choice between using Retpoline, Lfence (which
is the better AMD option, and more performant than retpoline), or IBRS
on Skylake and newer processors where it is strictly necessary, as well
as using IBPB whenever available.

It also supports virtualising IBRS for guest usage when the kernel has
chosen not to use it; a configuration I haven't seen in any of the Linux
patch series thusfar.

~Andrew