Message-ID: <20161201205923.o7trgf637pm5iiw5@treble>
Date:   Thu, 1 Dec 2016 14:59:23 -0600
From:   Josh Poimboeuf <jpoimboe@...hat.com>
To:     Jiri Slaby <jslaby@...e.cz>
Cc:     Miroslav Benes <mbenes@...e.cz>, Jiri Kosina <jikos@...nel.org>,
        Jessica Yu <jeyu@...hat.com>, linux-kernel@...r.kernel.org,
        live-patching@...r.kernel.org, Vojtech Pavlik <vojtech@...e.com>
Subject: Re: [RFC PATCH v1.9 07/14] x86/stacktrace: add function for
 detecting reliable stack traces

On Thu, Dec 01, 2016 at 09:28:37PM +0100, Jiri Slaby wrote:
> On 06/13/2016, 11:58 PM, Josh Poimboeuf wrote:
> > On Thu, Jun 09, 2016 at 10:31:01AM +0200, Jiri Slaby wrote:
> >> On 04/12/2016, 05:56 PM, Josh Poimboeuf wrote:
> >>>> We had been using unwinder for over a decade in SUSE but it stopped
> >>>> working for assembly recently (for obvious reasons). So having a working
> >>>> and reliable unwinder again is one of the top priorities for us.
> >>>
> >>> Since you already have an unwinder in SUSE, it sounds like what you need
> >>> most urgently is DWARF generation support in objtool so that your
> >>> unwinder will work again for asm code, right?  The kernel already emits
> >>> DWARF today (for C code), so an upstream unwinder isn't needed first.
> >>
> >> Right, that's exact.
> >>
> >>> That's high on my TODO list, and the coding is probably 70-80% done.  I
> >>> don't want to hold up progress...  But I don't really feel comfortable
> >>> passing the code off because it's quite a big feature with some major
> >>> changes to objtool.  Being the objtool author, I want to make sure to
> >>> give it my full attention.
> >>
> >> Sure. There is going to be no pressure to merge the v1 of the changes.
> >> But it would be nice to see what you have now so that we can start
> >> reviewing and proposing patches on the top of what you have :).
> > 
> > The code is still quite a mess and doesn't even work yet.  I think it
> > would be counterproductive for everybody if I were to share it at this
> > stage.
> > 
> >>> I'm spread quite thin at the moment but I do hope to have v1 of those
> >>> patches soon, hopefully May-ish.
> >>
> >> So I hope we will see something we can start working on now. I can
> >> really dedicate one-man hours to that work.
> > 
> > I do appreciate your offer to help.  Hopefully soon I'll get it to at
> > least a decently working and halfway readable state, and then I'll post
> > it.  Then any help will be much appreciated.
> 
> This has beaten us for way too long, so we are at the state we want to
> have the DWARF generation for asm in a very close future. So may I ask
> you again to send me what you have now? If not, I will start working on
> it from scratch to have something rather soon :).

I know I've been saying this for months now, but I really do plan to
have it ready "real soon now".  In fact I made a ton of progress on it
in October (had to rewrite the main objtool algorithm, basically) but
then I had to shelve it again to work on other things.

I honestly am planning on picking it back up as soon as I post the
consistency model v3, probably next week.

Here's its current state, though it ain't pretty:

  https://github.com/jpoimboe/linux/tree/objtool-dwarf

It only has DWARF analysis, not generation.  Generation will be a
logical extension of analysis: it already has an internal representation
of the DWARF state for each instruction; it just needs to convert it to
CFI and write it out.

Ignore all the crypto changes, those are frame pointer fixes, discovered
by the new more stringent frame pointer checks, since I completely
rewrote the frame pointer checking as a side effect of adding DWARF
analysis.

-- 
Josh

Powered by blists - more mailing lists