Gentoo Wiki


Wikipedia has an article on:
Stack-Smashing Protector

Stack Smashing Protection is implemented in Gentoo using the ProPolice Stack Smashing Protector from IBM. The deployment of SSP in Gentoo is maintained by the Hardened project.


SSP does several things to the layout of the stack frame to protect data from stack based buffer overflows in C and C++. It is a complete production solution; the protector protects local variables, passed arguments, the stack frame pointer, and the return address from being damaged and used for an exploit. It is not a debugging tool like mudflap, and so has some limitations. These include failure to protect data above buffers inside structures; failure to protect data in arrays of structures; and failure to protect data in other stack frames. This is because these issues cannot be addressed within the restrictions of the design goals of a production security device such as SSP.

SSP must not break binary compatibility between protected and non-protected code. It also must not incur unreasonable processing, memory, or storage overhead. This prevents SSP from being used to detect or prevent a number of things, such as damage in the heap; damage to foreign data outside the current stack frame; or anything that would require rearranging the layout of set data structures to detect or protect against.

Other solutions such as mudflap have a higher projected overhead. These are used for debugging purposes and may store pointers in hash tables for look-up upon access. They may also protect heap based data overflows and detect and locate a much wider range of program bugs. These systems are a great tool for debugging programs, but are impractical for deployment in production environments due to their high overhead, which is more likely to result in a visible tax on system performance than the skeletal logic added by SSP.

SSP protects local variables first. An SSP patched compiler will always rearrange local variables so that arrays are placed above other variables. Structures are placed below arrays but above other variables. This assures that overflows cannot damage other local variables; buffers can only damage other buffers, while structures can only damage other structures and buffers. This has no overhead costs.

SSP protects passed arguments. An SSP patched compiler will create new local variables and copy passed arguments into them, if the function contains a character array and -fstack-protector or -fstack-protector-all is used. Interestingly enough, if -fstack-protector-all is used, this protection is still applied heuristically instead of everywhere. This has minimal overhead costs, in the form of one extra instruction per passed argument.

SSP protects the stack frame pointer and return address as well. If a C or C++ source file is built with -fstack-protector, a __guard value is placed between these values and the local buffers in any function containing a local character array. This value is placed one byte past the end of the highest array, and is initialized to a randomly generated value chosen at program initialization. Before returning, the __guard value is checked for damage; if this check fails, the program immediately aborts, printing out a message about where the buffer was created at. If -fstack-protector-all is used, appropriate checks are always generated and a __guard is always placed just above the highest local variable. This generates a theoretical maximum of 8% processing overhead.

The theoretical maximum for __guard checking is 8%. The actual overhead is associated with two factors: function size and program usage patterns. If the functions are large and follow a long path without returning, a lot of code is executed between local __guard value initializations and checks. Most functions are several lines of code long, and many contain iterative loops; these will suffer negligible overhead. On the other hand, if -fstack-protector-all is not used, only functions with local character arrays are protected. In programs which rarely call functions using stack based buffers, the overhead during program run is negligible. Most programs and libraries are made up of code meeting both of these conditions.


If gcc is passed -fstack-protector, a simple heuristic to determine which functions should be __guard protected is used. On the other hand, passing -fstack-protector-all will __guard check all functions. These can be added to CFLAGS. It is recommended that -fstack-protector be present if -fstack-protector-all is used.

If hardened gcc is built, "-fstack-protector -fstack-protector-all" is added to CFLAGS automatically. These can be disabled with "-fno-stack-protector -fno-stack-protector-all". Alternately, "-fno-stack-protector-all -fstack-protector" will assure that -fstack-protector-all is disabled, backing down to heuristics determination of which functions to protect.

See also

Retrieved from ""

Last modified: Sat, 06 Sep 2008 07:15:00 +0000 Hits: 7,936