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 15:20:24 +0100
From:   Paolo Bonzini <pbonzini@...hat.com>
To:     "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/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)

and though we're obviously not wed to the specific debugfs paths and
names, I'd really like all of them to be available upstream too.  The
effect on performance (or lack of performance...) *is* there, so people
should be able to understand the effect on their workloads and customize
accordingly.

I hope that, after the first few weeks of panic, people will learn to
decide on a case-by-case basis whether to enable both PTI and IBRS/IBPB,
or none.  Distros will provide tuning guide and automatic tuning
profiles, etc., and the world will go on.

Paolo

ps: BTW^2 (and this is of course not about you, David) I'm disappointed
that for "Spectre" there was no discussion between upstream developers,
or between Linux vendors, or in fact hardly any discussion beyond "these
are the patches".  I understand that (unlike PTI) there was no back
story to cover up the actual vulnerability, but... grow up, folks.
Seriously, "these are the patches" won't fly with either upstream or
distros.

> The first variant (all they can do on current CPUs with a microcode
> update) is really slow, and thus retpoline is *very* much the preferred
> option to protect the kernel on current CPUs.

> Later CPUs will apparently have a better version of IBRS which is
> preferred, so we'll ALTERNATIVE out the retpoline if we discover we're
> running on one of those.
> 
> Public docs will, presumably, be forthcoming Real Soon Now™.
> 
> 
> 
> Amazon Web Services UK Limited. Registered in England and Wales with
> registration number 08650665 and which has its registered office at 60
> Holborn Viaduct, London EC1A 2FD, United Kingdom.