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 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
