linux-kernel - Re: [PATCH v4 0/3] 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: <20150520160904.GC16995@treble.redhat.com>
Date:	Wed, 20 May 2015 11:09:04 -0500
From:	Josh Poimboeuf <jpoimboe@...hat.com>
To:	Ingo Molnar <mingo@...nel.org>
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,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Andy Lutomirski <luto@...nel.org>,
	Denys Vlasenko <dvlasenk@...hat.com>,
	Brian Gerst <brgerst@...il.com>,
	Peter Zijlstra <a.p.zijlstra@...llo.nl>,
	Borislav Petkov <bp@...en8.de>,
	Andrew Morton <akpm@...ux-foundation.org>
Subject: Re: [PATCH v4 0/3] Compile-time stack frame pointer validation

On Wed, May 20, 2015 at 10:51:56AM -0500, Josh Poimboeuf wrote:
> On Wed, May 20, 2015 at 04:48:10PM +0200, Ingo Molnar wrote:
> > Yeah, so many of these seem to be 'leaf only' functions: functions 
> > that don't ever call functions themselves.
> 
> Yeah, good observation.
> 
> > So lets assume we always have CONFIG_FRAME_POINTERS=y.
> > 
> > If they don't set up a frame pointer then they in essence won't show 
> > up in the call chain
> 
> It's actually the _caller_ of the asm function which gets skipped in the
> trace.
> 
> (Though it doesn't really matter -- either way it's unreliable.)
> 
> > but normally they wouldn't because they call nothing.
> > 
> > If they trigger an exception/fault or if they get hit by an interrupt 
> > then I think we'll still correctly walk the stack - just those 
> > functions might be missing from the deterministic call chain, right? 
> > (it will still show up as a '?' entry.)
> 
> Right.  This patch set takes the more conservative approach of requiring
> _all_ callable asm functions to have frame pointer logic.  Which has the
> benefit of getting rid of some of the cases where we need the '?' stack
> entries.
> 
> > If they crash then we'll see them because the crashing RIP will be 
> > printed.
> > 
> > So I'm wondering what the x86 policy here should be: to create frame 
> > pointers in them or not. Cc:-ed a few more gents for thoughts.
> 
> I agree that frame pointers aren't strictly necessary for leaf
> functions.
> 
> I could easily relax the stackvalidate restrictions to exclude the
> checking of leaf functions.  In fact I think that would be more
> consistent with how gcc does it, so maybe that's a more reasonable
> approach.

I remembered another reason why I went with the more conservative
approach of requiring frame pointers in leaf functions.

It's often hard to pin down where an asm function begins and where it
ends.  For example, you might have something like:

ENTRY(callable_asm_func)
	jmp label
ENDPROC(callable_asm_func)

label:
	call some_c_function
	ret

If we were to relax the stackvalidate restrictions then we'd miss that
kind of (surprisingly common) situation, where a function jumps outside
of its scope.

Then again, I guess it would be pretty easy to add checks for that.

-- 
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/