Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752868AbeADLme (ORCPT + 1 other); Thu, 4 Jan 2018 06:42:34 -0500 Received: from atrey.karlin.mff.cuni.cz ([195.113.26.193]:58521 "EHLO atrey.karlin.mff.cuni.cz" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752783AbeADLmd (ORCPT ); Thu, 4 Jan 2018 06:42:33 -0500 Date: Thu, 4 Jan 2018 12:42:31 +0100 From: Pavel Machek To: "Woodhouse, David" Cc: Paolo Bonzini , Alan Cox , Linus Torvalds , Andi Kleen , tglx@linutronix.de, Greg Kroah-Hartman , Tim Chen , Linux Kernel Mailing List , Dave Hansen Subject: Re: Avoid speculative indirect calls in kernel Message-ID: <20180104114231.GB1702@amd> References: <20180103230934.15788-1-andi@firstfloor.org> <20180104015920.1ad7b9d3@alans-desktop> <1515054014.12987.75.camel@amazon.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <1515054014.12987.75.camel@amazon.co.uk> User-Agent: Mutt/1.5.23 (2014-03-12) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Return-Path: 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