linux-kernel - Re: [PATCH v7 02/11] x86/retpoline: Temporarily disable objtool when CONFIG

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:   Wed, 10 Jan 2018 11:12:33 +0100
From:   Peter Zijlstra <peterz@...radead.org>
To:     Josh Poimboeuf <jpoimboe@...hat.com>
Cc:     David Woodhouse <dwmw@...zon.co.uk>,
        Andi Kleen <ak@...ux.intel.com>, Paul Turner <pjt@...gle.com>,
        LKML <linux-kernel@...r.kernel.org>,
        Linus Torvalds <torvalds@...ux-foundation.org>,
        Greg Kroah-Hartman <gregkh@...ux-foundation.org>,
        Tim Chen <tim.c.chen@...ux.intel.com>,
        Dave Hansen <dave.hansen@...el.com>, tglx@...utronix.de,
        Kees Cook <keescook@...gle.com>,
        Rik van Riel <riel@...hat.com>,
        Andy Lutomirski <luto@...capital.net>,
        Jiri Kosina <jikos@...nel.org>, gnomes@...rguk.ukuu.org.uk,
        x86@...nel.org
Subject: Re: [PATCH v7 02/11] x86/retpoline: Temporarily disable objtool when
 CONFIG_RETPOLINE=y

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@...ux.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.