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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Thu, 26 Mar 2015 00:24:45 +0100 (CET)
From:	Jiri Kosina <jkosina@...e.cz>
To:	Josh Poimboeuf <jpoimboe@...hat.com>
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 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).

-- 
Jiri Kosina
SUSE Labs
--
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/