Re: [PATCH v7 02/11] x86/retpoline: Temporarily disable objtool when CONFIG_RETPOLINE=y

[Peter Zijlstra <peterz@infradead.org>]

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 <ak@linux.intel.com>
> > 
> > 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.