Gentoo Linux PIE-SSP Documentation
Introduction to Randomization and Stack Protection
First of all, the PaX homepage has moved to http://pax.grsecurity.net,
please update your bookmarks.
While the goal of the PaX suite has remained the same ever since,
preventing memory related security vulnerabilities, there has been major
advancements in the progress of getting similar and coexisting kernel
patches into the attention of the wide public.
Even though linear stack smashing attacks, formatstring overflows and
return to libc style attacks cannot be fully prevented or suppressed by
effective randomization of the running executable, there seems to be a
wide consent amongst information security experts and GNU/Linux
distributions that it does help putting up another barrier (see chapter
The outstanding support and help from the Gentoo toolchain main developer
and coordinator, Martin Schlemmer as well as Dr. Hiroaki Etoh and moid
from the OpenBSD team with the closer integration of the SSP patch into
the Gentoo toolchain and userland has proven the common goals and
commitments between developers throughout the world striving for better
support and acceptance of technology that provides a security oriented,
high quality, automatic response to simple linear stack overflow attempts.
Kernels with PaX patches
The positive feedback generated by users who are enhanced by the
grsecurity patch being included as a standard security measure in the
native gentoo-sources leads us to uphold the support for grsecurity in
this common practice kernel.
While the hardened-sources has been abolished in favour of the ongoing
concurrent development of fully supported MAC/ACL schemes in Gentoo
Hardened, selinux-sources and grsec-sources can benefit from the thorough
implementation of a true PIE (position independent executables) and SSP
(stack smashing protector) environment via the incorporated PaX patch.
Chris Pebenito holds up the high quality and standard of the
selinux-sources while keeping in touch with the PaX developments and
introducing randomization and userland features of PIE and SSP via PaX or
correlating patches according to the requirements of the solutions needed
by our partners.
The hardened-sources are maintained by hardened team and is the ideal
kernel to use with a hardened toolchain.
GNU C Compiler and the history of PIE support
As described in the introduction, in the last year we have seen major
advancements (and confusion) in the GNU upstream toolchain regarding the
implementation of a system wide scenario for storing information about
stack protection requirements and randomization of executables via PIE
(position independent executables) support.
When the first PaX randomization patches came out, a modification to the
GNU C compiler specs file was needed to create so-called
This means that these days the linker was told to explicitly link -fPIC
(gcc function to force the creation of position independent code) compiled
.o object files with a interp.o interpreter field pointing to "/lib/ld.so"
from glibc on the intel platform, using a special custom formed crt1S.o
which was able to set up the addresses of "_main", "_init" (recent glibc:
"__libc_csu_init") and "_fini" (recent glibc: "__libc_csu_fini") in the
"_start" function in a position independent manner.
So basically a setup like in a shared library was used to set up the PIC
(position independent code) addressing of the data and the code segments
in the executable that needs to be started via the main() function.
There has been a bug on nonintel arches regarding the setup of the PIC
register (%r19 on parisc) for statically linked binaries.
Since this bug has been fixed on all arches we can support, it is now also
safe to create this library-like PIC setup for statically compiled
When Ingo Molnar from Redhat started to introduce the execshield kernel
patches, the developers at Redhat also wanted to make use of the "hot and
new" randomization for binaries, so Jakub Jelinek invested a lot of time
in the preparation of the toolchain (binutils, glibc, gcc) to introduce
the -pie flag which generates these binaries with the correct interpreter
and a glibc provided Scrt1.o.
With Russell Coker involved in the Fedora distribution of Redhat, the
future directions to an Execshield based selinux setup with -pie support
from the toolchain are a visible example for the integration of security
improvements in a full-scale commercial office and home user distribution.
Russell Coker also seems to be interested in supporting selinux for
However, the technical approach to support compatibility needs of
applications (java apps, gcc heuristically sets executable stack for
nested functions) over default security measures (as implemented in PaX
kernels) may not suit environments with higher risk analysis and threat
A proven gcc extension for linear stack overflow protection
When the OpenBSD team discovered SSP as their favourite utility to limit
the possibility of linear stack overflows, they also evaluated the stack
smash handler functions and found out that the best way to introduce SSP
into their toolchain was a modification of the dynamic linker for
executables requiring that no standard libraries were included (boot
loaders!) and giving all other dynamically linked applications the chance
to retrieve the guard object and the necessary related functions via their
standard C library.
Thus, the dynamically linked executables and shared libraries protected
via propolice were using one exact shared copy of the __guard reference
and the needed functions for setup and smash handling in a single
Statically linked executables will have their own copy of __guard and the
functions to work properly.
On the Linux platform, Dr. Etoh decided to put the __guard, the
__guard_setup and the __stack_smash_handler into the libgcc of the gcc
This led to problems with big packages like apache2 and mod_php4 producing
false positives because the wrong local __guard copies in shared libraries
and/or the main executable were used by different __stack_smash_handlers,
this odd momentum has been resolved and isolated in gdb sessions by pipacs
from the PaX team.
Having moid from the OpenBSD team to help us mitigating this negative side
effect of the GNU C compiler and working close together with Dr. Etoh from
the IBM labs in japan gave us the chance to introduce the first
glibc-based SSP setup for userland in GNU/Linux for Gentoo-Linux at all!
( PIE-SSP it works! )
Position Independent Executables with Propolice support
On a Gentoo system this is currently accomplished by merging gcc:
Code Listing 5.1: Emerging gcc
# USE="hardened pic" emerge sys-devel/gcc
While a hardened gcc starts the transparent conversion of a system to position independence for your binaries via making use of gcc spec file handling.
Once the gcc has been equipped with that new specs file, a package or a kernel building can only return to the conventional building behaviour when it feeds the correct CFLAGS and LDFLAGS to the build process.
As an example lets try the rebuilding our chpax binary as a position independent
executable. We can use the file(1) command to determine if we
in fact we are building our executables as ET_EXEC or ET_DYN.
The first example here we have chpax built as a ET_DYN
and the second one is chpax not built as a standard ET_EXEC file.
Code Listing 5.2: Example files
# file /sbin/chpax
/sbin/chpax: ELF 32-bit LSB shared object, Intel 80386, version 1 \
# file /sbin/chpax
/sbin/chpax: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), for \
GNU/Linux 2.0.0, dynamically linked (uses shared libs), stripped
The gcc package has been designed to easily revert back to a conventional building environment behaviour in case of problems.
Users can restore the original gcc specs file behaviour at any time by calling the gcc-config utility on the commandline. gcc-config -l ; gcc-config
Ebuilds that experience problems with the a hardened gcc automatic transparency can evaluate the existence of the hardened gcc package on the target system and use compatibility CFLAGS to restore the original gcc behaviour during the emerge.
Using distcc with hgcc
Lisa Marie Seelye says you need the same hgcc and gcc versions on all distcc host volunteer machines.
Credits and Reference