Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1760329AbcLAU71 (ORCPT ); Thu, 1 Dec 2016 15:59:27 -0500 Received: from mx1.redhat.com ([209.132.183.28]:45258 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753335AbcLAU7Z (ORCPT ); Thu, 1 Dec 2016 15:59:25 -0500 Date: Thu, 1 Dec 2016 14:59:23 -0600 From: Josh Poimboeuf To: Jiri Slaby Cc: Miroslav Benes , Jiri Kosina , Jessica Yu , linux-kernel@vger.kernel.org, live-patching@vger.kernel.org, Vojtech Pavlik Subject: Re: [RFC PATCH v1.9 07/14] x86/stacktrace: add function for detecting reliable stack traces Message-ID: <20161201205923.o7trgf637pm5iiw5@treble> References: <1f8c648ed8b8eb49a75f5a6cacf8b7ca76f44fa9.1458933243.git.jpoimboe@redhat.com> <20160404175437.gjj2ghphzv5foh4j@treble.redhat.com> <570BB1AE.6090502@suse.cz> <20160412155658.uuz5jbtnmw3teaey@treble> <91e1f8fc-1a97-709c-3846-16b9ce694246@suse.cz> <20160613215855.66xvswctxdy2bbrj@treble> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.6.0.1 (2016-04-01) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.39]); Thu, 01 Dec 2016 20:59:25 +0000 (UTC) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 3197 Lines: 68 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