Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752497AbeADJsc (ORCPT + 1 other); Thu, 4 Jan 2018 04:48:32 -0500 Received: from out2-smtp.messagingengine.com ([66.111.4.26]:35475 "EHLO out2-smtp.messagingengine.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751721AbeADJsb (ORCPT ); Thu, 4 Jan 2018 04:48:31 -0500 X-ME-Sender: Date: Thu, 4 Jan 2018 10:48:36 +0100 From: Greg Kroah-Hartman To: Paul Turner Cc: LKML , Linus Torvalds , "Woodhouse, David" , Tim Chen , Dave Hansen , tglx@linuxtronix.de, Kees Cook , Rik van Riel , Peter Zijlstra , Andy Lutomirski , Jiri Kosina , gnomes@lxorguk.ukuu.org.uk Subject: Re: [RFC] Retpoline: Binary mitigation for branch-target-injection (aka "Spectre") Message-ID: <20180104094836.GA31023@kroah.com> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.9.2 (2017-12-15) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Return-Path: On Thu, Jan 04, 2018 at 01:24:41AM -0800, Paul Turner wrote: > On Thu, Jan 4, 2018 at 1:10 AM, Paul Turner wrote: > > Apologies for the discombobulation around today's disclosure. Obviously the > > original goal was to communicate this a little more coherently, but the > > unscheduled advances in the disclosure disrupted the efforts to pull this > > together more cleanly. > > > > I wanted to open discussion the "retpoline" approach and and define its > > requirements so that we can separate the core > > details from questions regarding any particular implementation thereof. > > > > As a starting point, a full write-up describing the approach is available at: > > https://support.google.com/faqs/answer/7625886 > > > > The 30 second version is: > > Returns are a special type of indirect branch. As function returns are intended > > to pair with function calls, processors often implement dedicated return stack > > predictors. The choice of this branch prediction allows us to generate an > > indirect branch in which speculative execution is intentionally redirected into > > a controlled location by a return stack target that we control. Preventing > > branch target injections (also known as "Spectre") against these binaries. > > > > On the targets (Intel Xeon) we have measured so far, cost is within cycles of a > > "native" indirect branch for which branch prediction hardware has been disabled. > > This is unfortunately measurable -- from 3 cycles on average to about 30. > > However the cost is largely mitigated for many workloads since the kernel uses > > comparatively few indirect branches (versus say, a C++ binary). With some > > effort we have the average overall overhead within the 0-1.5% range for our > > internal workloads, including some particularly high packet processing engines. > > > > There are several components, the majority of which are independent of kernel > > modifications: > > > > (1) A compiler supporting retpoline transformations. > > An implementation for LLVM is available at: > https://reviews.llvm.org/D41723 Nice, thanks for the link and the write up. There is also a patch for gcc floating around somewhere, does anyone have the link for that? thanks, greg k-h