----- Original Message -----
From: "Robert Connolly" <rob...@linuxfromscratch.org>
To: <hlfs-dev@linuxfromscratch.org>
Sent: Tuesday, November 02, 2010 4:22 AM
Subject: development
> Do any of you have opinions about anything here?
A choice has to be made as to live in the edge of the development, or use
more common method.
Less patching mean upgrade is easier and bug fix release are simplier to use
without headache.
We have used on ipcop some of the hardening method used on HLFS but far from
everything.
Our base code is LFS with a few differences in binutils/gcc/glibc.
Basically we are like LFS plus a general
CFLAGS="-Os -march=${MACHINE} -mtune=pentium -pipe -fomit-frame-pointer -D_F
ORTIFY_SOURCE=2 -fstack-protector-all -fPIE -Wl,-z,now"
LDFLAGS="-Wl,--hash-style=gnu"
and glibc compiled with
--enable-bind-now \
--enable-stackguard-randomization \
--enable-omitfp \
We have good test suite result with glibc-2.11.2, gcc-4.4.5 and every other
packages (a bit less good on pcc and sparc-64).
I haven't twisted yet gcc spec (for -D_FORTIFY_SOURCE=2, pie,
fstack-protector-all) mostly because I try to start simple and check
everything is fine before continuing with more sophisticated changes.
Is this really better to change gcc spec instead of giving CFLAGS with same
requirement?
I suppose the difference may come from packages that somehow filter CFLAGS
content. Same package may still be hardened if gcc default behavior is to be
hardened except when explicitely required not to compile hardened.
One drawback of changing gcc spec is that the testsuite need to be changed
to support the new behavior.
Gilles
--
http://linuxfromscratch.org/mailman/listinfo/hlfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
