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


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