linux-kernel - Re: Avoid speculative indirect calls in kernel

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20180104114231.GB1702@amd>
Date:   Thu, 4 Jan 2018 12:42:31 +0100
From:   Pavel Machek <pavel@....cz>
To:     "Woodhouse, David" <dwmw@...zon.co.uk>
Cc:     Paolo Bonzini <pbonzini@...hat.com>,
        Alan Cox <gnomes@...rguk.ukuu.org.uk>,
        Linus Torvalds <torvalds@...ux-foundation.org>,
        Andi Kleen <andi@...stfloor.org>, tglx@...utronix.de,
        Greg Kroah-Hartman <gregkh@...ux-foundation.org>,
        Tim Chen <tim.c.chen@...ux.intel.com>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        Dave Hansen <dave.hansen@...el.com>
Subject: Re: Avoid speculative indirect calls in kernel

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