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]
Message-ID: <20180110101233.GA6094@worktop.programming.kicks-ass.net>
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.

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ