Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S965142AbeAJKMp (ORCPT + 1 other); Wed, 10 Jan 2018 05:12:45 -0500 Received: from bombadil.infradead.org ([65.50.211.133]:54068 "EHLO bombadil.infradead.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754052AbeAJKMl (ORCPT ); Wed, 10 Jan 2018 05:12:41 -0500 Date: Wed, 10 Jan 2018 11:12:33 +0100 From: Peter Zijlstra To: Josh Poimboeuf Cc: David Woodhouse , Andi Kleen , Paul Turner , LKML , Linus Torvalds , Greg Kroah-Hartman , Tim Chen , Dave Hansen , tglx@linutronix.de, Kees Cook , Rik van Riel , Andy Lutomirski , Jiri Kosina , gnomes@lxorguk.ukuu.org.uk, x86@kernel.org Subject: Re: [PATCH v7 02/11] x86/retpoline: Temporarily disable objtool when CONFIG_RETPOLINE=y Message-ID: <20180110101233.GA6094@worktop.programming.kicks-ass.net> References: <1515508997-6154-1-git-send-email-dwmw@amazon.co.uk> <1515508997-6154-3-git-send-email-dwmw@amazon.co.uk> <20180110055806.gqdxpk4urvew253b@treble> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20180110055806.gqdxpk4urvew253b@treble> User-Agent: Mutt/1.5.22.1 (2013-10-16) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Return-Path: On Tue, Jan 09, 2018 at 11:58:06PM -0600, Josh Poimboeuf wrote: > On Tue, Jan 09, 2018 at 02:43:08PM +0000, David Woodhouse wrote: > > From: Andi Kleen > > > > objtool's assembler currently cannot deal with the code generated by the > > retpoline compiler and throws hundreds of warnings, mostly because it sees > > calls that don't have a symbolic target. > > > > Exclude all the options that rely on objtool when RETPOLINE is active. > > > > This mainly means that the kernel has to fallback to use the frame pointer > > unwinder and livepatch is not supported. > > > > Josh is looking into resolving the issue. > > I have a fix brewing for this, in two parts: > > - Part 1 will allow objtool to understand the flow *around* the > retpolines (but not *inside* them). Which basically means that ORC > will still get confused if it tries to unwind from inside a retpoline, > but otherwise it should work fine. This code is pretty much done, > just need to do some testing with it first. This should allow us to > re-enable objtool and friends: ORC, reliable stacks, livepatch > consistency model. > > - Part 2 will add ORC annotations for inside the retpolines. This will > be a little harder, but I have my fingers crossed that it's do-able > within a week or so. I know this has been raised before, but why isn't it a good idea to get compiler generated sections for this stuff? Ideally we'd been able to completely patch out all retpoline stuff at runtime once we have fixed hardware, right? Currently the best we can do is call into the generic thunk and then jump there to the intended target, but that's still overhead.