[lkml]   [2018]   [Jan]   [3]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: Avoid speculative indirect calls in kernel
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.


 \ /
  Last update: 2018-01-04 03:11    [W:0.121 / U:1.320 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site