[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1515066469.12987.112.camel@amazon.co.uk>
Date: Thu, 4 Jan 2018 11:47:49 +0000
From: "Woodhouse, David" <dwmw@...zon.co.uk>
To: Pavel Machek <pavel@....cz>
CC: Paolo Bonzini <pbonzini@...hat.com>,
Alan Cox <gnomes@...rguk.ukuu.org.uk>,
Linus Torvalds <torvalds@...ux-foundation.org>,
Andi Kleen <andi@...stfloor.org>, <tglx@...utronix.de>,
Greg Kroah-Hartman <gregkh@...ux-foundation.org>,
Tim Chen <tim.c.chen@...ux.intel.com>,
"Linux Kernel Mailing List" <linux-kernel@...r.kernel.org>,
Dave Hansen <dave.hansen@...el.com>
Subject: Re: Avoid speculative indirect calls in kernel
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.
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...
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™.
Download attachment "smime.p7s" of type "application/x-pkcs7-signature" (5210 bytes)
Powered by blists - more mailing lists