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]

Date:   Thu, 4 Jan 2018 08:20:14 +0000
From:   "Woodhouse, David" <dwmw@...zon.co.uk>
To:     Paolo Bonzini <pbonzini@...hat.com>,
        Alan Cox <gnomes@...rguk.ukuu.org.uk>
CC:     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 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.

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).


Download attachment "smime.p7s" of type "application/x-pkcs7-signature" (5210 bytes)