linux-kernel - Re: [RFC PATCH v1.9 07/14] x86/stacktrace: add function for detecting reliable stack traces

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: <20160412155658.uuz5jbtnmw3teaey@treble>
Date:	Tue, 12 Apr 2016 10:56:58 -0500
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 Mon, Apr 11, 2016 at 04:16:14PM +0200, Jiri Slaby wrote:
> On 04/04/2016, 07:54 PM, Josh Poimboeuf wrote:
> > On Thu, Mar 31, 2016 at 03:03:16PM +0200, Miroslav Benes wrote:
> >> On Fri, 25 Mar 2016, Josh Poimboeuf wrote:
> >>
> >>> diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
> >>> index 2dc18605..76274b8 100644
> >>> --- a/arch/x86/Kconfig
> >>> +++ b/arch/x86/Kconfig
> >>> @@ -138,6 +138,7 @@ config X86
> >>>  	select HAVE_PERF_REGS
> >>>  	select HAVE_PERF_USER_STACK_DUMP
> >>>  	select HAVE_REGS_AND_STACK_ACCESS_API
> >>> +	select HAVE_RELIABLE_STACKTRACE		if X86_64 && FRAME_POINTER
> >>
> >> I understand we have to rely on frame pointer for now. Do you plan to 
> >> switch to dwarf unwinder one day in the future? IOW is there a plan to 
> >> implement dwarf stuff generation in objtool and then to have a dwarf-based 
> >> stack unwinder upstream and to use it for live patching? 
> > 
> > Yes, adding DWARF validation and generation to objtool and creating a
> > DWARF unwinder upstream are all planned, hopefully soon.
> 
> I may seem to be obtrusive, but here, I would like to offer my help
> again. If you need any kind of help with the unwinder, I can definitely
> help with that. Be it coding, testing, ideas discussion or anything else.
> 
> 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.

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.

I'm spread quite thin at the moment but I do hope to have v1 of those
patches soon, hopefully May-ish.

-- 
Josh