linux-kernel - Re: [RFC PATCH 0/2] Compile-time stack frame pointer validation

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: <20150325233455.GA15796@treble.redhat.com>
Date:	Wed, 25 Mar 2015 18:34:55 -0500
From:	Josh Poimboeuf <jpoimboe@...hat.com>
To:	Jiri Kosina <jkosina@...e.cz>
Cc:	Thomas Gleixner <tglx@...utronix.de>,
	Ingo Molnar <mingo@...hat.com>,
	"H. Peter Anvin" <hpa@...or.com>, Michal Marek <mmarek@...e.cz>,
	Peter Zijlstra <peterz@...radead.org>, x86@...nel.org,
	live-patching@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [RFC PATCH 0/2] Compile-time stack frame pointer validation

On Thu, Mar 26, 2015 at 12:24:45AM +0100, Jiri Kosina wrote:
> On Wed, 25 Mar 2015, Josh Poimboeuf wrote:
> 
> > In discussions around my live kernel patching consistency model RFC [1], 
> > Peter and Ingo correctly pointed out that stack traces aren't reliable.  
> > And as Ingo said, there's no "strong force" which ensures we can rely on 
> > them.
> > 
> > So I've been thinking about how to fix that.  My goal is to eventually 
> > make stack traces reliable.  Or at the very least, to be able to detect 
> > at runtime when a given stack trace *might* be unreliable.  But improved 
> > stack traces would broadly benefit the entire kernel, regardless of the 
> > outcome of the live kernel patching consistency model discussions.
> [ ... snip ... ]
> 
> I haven't really gone through your patchset thoroughly yet, but I just 
> wanted to make sure that you are aware of existing DWARF-based stack 
> unwinder which exists for the kernel.
> 
> It's not merged in mainline (one of the reasons being disagreements about 
> bugfixes between Jan and Linus), but we've been carrying it in SUSE 
> kernels as an out-of-tree patch for quite some time, and it really makes 
> stack dumps much more reliable and understandable.
> 
> You can see it for example here:
> 
> 	http://kernel.suse.com/cgit/kernel-source/tree/patches.suse/stack-unwind
> 
> (and some merge attempt failures due to disagreements between Jan and 
> Linus, not really completely related to the actual code itself, in LKML 
> archives).

Thanks, that could be helpful.  I also found a nice (currently only
32-bit) DWARF unwinder in arch/sh/kernel/dwarf.c.

The DWARF metadata has a reputation for being unreliable, but I have
some ideas on how to improve it for future patch sets, with both
compile-time and runtime validations.

-- 
Josh
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/