Re: [PATCH v7 2/4] x86/stackvalidate: Compile-time stack validation

[Peter Zijlstra <peterz@infradead.org>]

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? ;-)