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
