lkml.org 
[lkml]   [2015]   [Jul]   [14]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH v7 2/4] x86/stackvalidate: Compile-time stack validation
On Tue, Jul 14, 2015 at 11:08:58PM +0200, Peter Zijlstra wrote:
> On Tue, Jul 14, 2015 at 12:14:08PM -0500, Josh Poimboeuf wrote:
> > This adds a CONFIG_STACK_VALIDATION option which enables a host tool
> > named stackvalidate which runs at compile time. It analyzes every .o
> > file and ensures the validity of its stack metadata. It enforces a set
> > of rules on asm code and C inline assembly code so that stack traces can
> > be reliable.
> >
> > Currently it checks frame pointer usage. I plan to add DWARF CFI
> > validation as well.
> >
> > For each function, it recursively follows all possible code paths and
> > validates the correct frame pointer state at each instruction.
> >
> > It also follows code paths involving special sections, like
> > .altinstructions, __jump_table, and __ex_table, which can add
> > alternative execution paths to a given instruction (or set of
> > instructions). Similarly, it knows how to follow switch statements, for
> > which gcc sometimes uses jump tables.
> >
> > To achieve the validation, stackvalidate enforces the following rules:
> >
> > 1. Each callable function must be annotated as such with the ELF
> > function type. In asm code, this is typically done using the
> > ENTRY/ENDPROC macros. If stackvalidate finds a return instruction
> > outside of a function, it flags an error since that usually indicates
> > callable code which should be annotated accordingly.
> >
> > 2. Conversely, each section of code which is *not* callable should *not*
> > be annotated as an ELF function. The ENDPROC macro shouldn't be used
> > in this case.
> >
> > 3. Each callable function which calls another function must have the
> > correct frame pointer logic, if required by CONFIG_FRAME_POINTER or
> > the architecture's back chain rules. This can by done in asm code
> > with the FRAME/ENDFRAME macros.
> >
> > 4. Dynamic jumps and jumps to undefined symbols are only allowed if:
> >
> > a) the jump is part of a switch statement; or
> >
> > b) the jump matches sibling call semantics and the frame pointer has
> > the same value it had on function entry.
> >
> > 5. A callable function may not execute kernel entry/exit instructions.
> > The only code which needs such instructions is kernel entry code,
> > which shouldn't be in callable functions anyway.
>
>
> How (if it does at all) deal with function-trace / -pg -fprofile-arcs
> things? Does it silently ignore the __mcount calls and assumes ftrace
> knows wtf its doing? ;-)

Adding Steven to CC to keep me honest.

In the case of "-pg -mfentry", which is what ftrace has relied on for
the past few years for newer versions of gcc, stackvalidate silently
ignores __fentry__ calls and assumes that ftrace indeed knows wtf it's
doing. I don't see a problem there as long as the ftrace handler
doesn't sleep.

I haven't run stackvalidate on the old "-pg" mcount non-fentry stuff,
but I think it creates a stack frame before calling mcount, so it should
be fine.

I don't know much about -fprofile-arcs, but as far as I can tell, it's
only used for gcov.

--
Josh


\
 
 \ /
  Last update: 2015-07-14 23:41    [W:0.195 / U:0.604 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site