Messages in this thread | | | Subject | Re: Avoid speculative indirect calls in kernel | From | Paolo Bonzini <> | Date | Thu, 4 Jan 2018 03:11:08 +0100 |
| |
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
| |