Hi Dean,
Im trying the same thing (gcc 4.6.3), but on an arm processor. I succesfully
finished lfs standard, and am now trying hlfs. On the stage 1 section,
modifying linux.h to add the fpic options looks a bit different. The file in
question is "linx-eabi.h" under gcc/config/arm, and the "#define CC1_SPEC line
looks like this:
#define CC1_SPEC. \
LINUX_OR_ANDROID_CC (GNU_USER_TARGET_CC1_SPEC, \
GNU_USER_TARGET_CC1_SPEC " "
ANDROID_CC1_SPEC)
Any ideas how i format this to add the fpic part?
Thanks,
Elf
Sent from my iPad
On 2012-03-29, at 12:00 AM, Dean Takemori <[email protected]> wrote:
> 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>
>
>
>
> --
> http://linuxfromscratch.org/mailman/listinfo/hlfs-dev
> FAQ: http://www.linuxfromscratch.org/faq/
> Unsubscribe: See the above information page
--
http://linuxfromscratch.org/mailman/listinfo/hlfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
