Re: Avoid speculative indirect calls in kernel

["Woodhouse, David" <dwmw@amazon.co.uk>]

[-- Attachment #1: Type: text/plain, Size: 1656 bytes --]

On Thu, 2018-01-04 at 03:11 +0100, Paolo Bonzini wrote:
> On 04/01/2018 02:59, Alan Cox wrote:
> >> But then, exactly because the retpoline approach adds quite some cruft
> >> and leaves something to be desired, why even bother?
> >
> > Performance
> 
> Dunno.  If I care about mitigating this threat, I wouldn't stop at
> retpolines even if the full solution has pretty bad performance (it's
> roughly in the same ballpark as PTI).  But if I don't care, I wouldn't
> want retpolines either, since they do introduce a small slowdown (10-20
> cycles per indirect branch, meaning that after a thousand such papercuts
> they become slower than the full solution).
> 
> A couple manually written asm retpolines may be good as mitigation to
> block the simplest PoCs (Linus may disagree), but patching the compiler,
> getting alternatives right, etc. will take a while.  The only redeeming
> grace of retpolines is that they don't require a microcode update, but
> the microcode will be out there long before these patches are included
> and trickle down to distros...  I just don't see the point in starting
> from retpolines or drawing the line there.

No, really. The full mitigation with the microcode update and IBRS
support is *slow*. Horribly slow.

By using retpoline, we avoid the need to set IBRS on *every* entry into
the kernel. It gives you *most* of that performance back.

It's horrid, but it seems to be the best option we have. And in my
original patch set, it goes away almost completely if it isn't being
used. (Apart from the fact that your eyes may still bleed; I can't do
anything about that. Sorry).


[-- Attachment #2: smime.p7s --]
[-- Type: application/x-pkcs7-signature, Size: 5210 bytes --]