On Thu 2018-01-04 08:20:14, Woodhouse, David wrote:
> 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.
What is IBRS? Invalidate BRanch prediction bufferS?
> 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).
Bleeding eyes sound like quite serious side-effect :-).
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures)
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
