Having successfully transitioned my personal build tree to gcc-4.6.3 and kernel-3.2.13 + grsec-2.9, here's a few notes.
GCC: Earlier incarnations of the HLFS book modified the gcc version string so
that "gcc -v" would indicate modifications to upstream behavior. Recent gcc
releases can now do the same by passing --with-pkgversion to the configure
script.
configure --with-pkgname="HLFS SSP FORTIFY [`date`]" (etc ...)
GCC: There was an upstream change to gcc-4.6.x that prevents the default-fortify
patches from earlier versions from working properly.
The earliest symptom is that the gcc-4.5.x fortify patch will apply, build and
the
resultant compiler will appear to pass the HLFS book's memcpy test, but the
final
system's glibc build will fail in syslog.c with a "function body not available"
See:
http://sourceware.org/bugzilla/show_bug.cgi?id=10375
http://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo/src/patchsets/gcc/4.6.2/gentoo/01_all_joined-cpp-defs.patch
Attached is a patch against gcc-4.6.3 which fixes the issue, but the following
test strategy will catch the problem earlier in the build process.
After running the "dummy.c" test in the Temporary GCC Pass 2 stage, compile the
memcpy.c test listed in the Final Tools GCC chapter.
1) First check the default behavior of the compiler
rm -f memcpy
/tools/bin/gcc -B/tools/lib memcpy.c -o memcpy
./memcpy 10
1020202020
./memcpy 11
*** stack smashing detected *** ./memcpy terminated
2) With optimization turned on, FORTIFY_SOURCE should catch the problem instead
rm -f memcpy
/tools/bin/gcc -B/tools/lib -O memcpy.c -o memcpy
./memcpy 10
1020202020
./memcpy 11
*** buffer overflow detected *** ./memcpy terminated
3) Now ensure we can turn on optimization with FORTIFY_SOURCE off if we want.
If this
test terminates with a buffer overflow, that indicates that FORTIFY_SOURCE is
still on.
rm -f memcpy
/tools/bin/gcc -B/tools/lib -O -U_FORTIFY_SOURCE memcpy.c -o memcpy
./memcpy 10
1020202020
./memcpy 11
*** stack smashing detected *** ./memcpy terminated
4) And check that we can run with both off both if we want. If this test
terminates with a buffer overflow, that indicates that FORTIFY_SOURCE is still
on. If
it terminates with a stack smashing warning, then the stack-protector is still
on.
rm -f memcpy
/tools/bin/gcc -B/tools/lib -O -U_FORTIFY_SOURCE -fno-stack-protector
memcpy.c -o memcpy
./memcpy 10
1020202020
./memcpy 11
10202020202
Otherwise, HLFS's 4.5.3-fstack_protector patch and the 4.6.2-fpie patch I posted
earlier appear to work as intended to provide a default hardened compiler
KERNEL: Current HLFS development instructs compiling the kernel and modules with
make CC="gcc -fno-PIE -no-fatal-warnings"
But doing this for the entire build may be overkill; the only linker warning
that
I've found that makes a difference is in grsecurity's linker version check and
this
can be fixed after applying the grsec patch with
sed 's/cc-ldoption,/cc-ldoption, -Wl$(comma)--no-fatal-warnings/'
Makefile
The rest of the build can then be made with
make scripts
make tools/gcc
make CC="gcc -fno-PIE"
KERNEL: For anyone doing HLFS Live CDs; AUFS and grsecurity get along better
these
days due to the Pax team's creation of a gcc-plugin to do "constification."
Just
build the kernel and modules with
make DISABLE_PAX_CONSTIFY_PLUGIN=y CC="gcc -fno-PIE"
make DISABLE_PAX_CONSTIFY_PLUGIN=y CC="gcc -fno-PIE" modules_install
Note that ALL modules, not just the ones compiled (like the frandom module)
should
define this to load correctly.
SECURITY: Tobias Klein hosts a tool that can check the status of
kernel-hardening
features, PIE, FORTIFY and PaX header status of binaries and processes. See
http://www.trapkit.de/tools/checksec.html
Note that the kernel heap hardening patchset it refers to is no longer
maintained
(see http://www.subreption.com/products/kernheap)
Happy Hacking
-dean takemori
gcc-4.6.3-fortify_source-0.patch
Description: Binary data
-- http://linuxfromscratch.org/mailman/listinfo/hlfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
