Linux Applications Debugging Techniques/Stack corruption

Stack corruption is rather hard to diagnose. Luckily, gcc 4.x can instrument the code to check for stack corruption:


 * -fstack-protector  Add stack protection to functions that have “alloca” or have a (signed or unsigned) char array with size > 8 (SSP_BUFFER_SIZE)
 * -fstack-protector-strong  To more functions, see below
 * -fstack-protector-all  To ALL functions

gcc will add guard variables and code to check for buffer overflows upon exiting a function. A quick example:

When run, the program will dump core:

-fstack-protector-strong
Added by google to gcc.

Benefit - gain big performance while sacrificing little security (for scenarios using -fstack-protector-all)

Background - some times stack-protector is too-simple while stack-protector-all over-kills, for example, to build one of our core systems, we forcibly add "-fstack-protector-all" to all compile commands, which brings big performance penalty (due to extra stack guard/check insns on function prologue and epilogue) on both atom and arm. To use "-fstack-protector" is just regarded as not secure enough (only "protects" <2% functions) by the system secure team. "-fstack-protector-strong" hits the balance between "-fstack-protector" and "-fstack-protector-all".

Adds the check to a function:


 * if any of its local variable’s address is taken, as part of the RHS of an assignment
 * or if any of its local variable’s address is taken as part of a function argument.
 * or if it has an array, regardless of array type or length
 * or if it has a struct/union which contains an array, regardless of array type or length.
 * or if function has register local variables

See http://gcc.gnu.org/ml/gcc-patches/2012-06/msg00974.html