Re: Avoid speculative indirect calls in kernel

[Paolo Bonzini]

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.

Paolo