Re: [PATCH v4 0/3] Compile-time stack frame pointer validation

Josh Poimboeuf
2015-05-20T16:10:10Z

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