To do list (February 2011):

Robert Connolly robert at linuxfromscratch.org
Wed Feb 23 14:15:14 PST 2011


On Tuesday 22 February 2011 13:12:43 you wrote:
> Selon Robert Connolly <robert at linuxfromscratch.org>:
> > Hi.
> > 
> > This is a short to-do list for immediate needs. If any of you have idea
> > please feel free to discuss it or add to it, etc.
> > 
> > This is all easy and doable stuff. The book seems to be building without
> > issues now, with SSP, _FORTIFY_SOURCE, and -fPIE enabled in GCC.
> > More is coming, please be patient.
> > 
> > The GCC test suite is the only test suite that needs to be fixed. All the
> > rest are good, as far as I know. This was fixed before by using the GCC
> > pass 1 specs (/tools/bin/x86_64-lfs-linux-gnu-gcc -dumpspecs) copied to
> > gcc/specs in the gcc-build/ directory before 'make check', however GCC
> > pass 1 is a cross compiler now, and when I tried to use them the test
> > results were terrible.
> 
> We used a similar trick on ipcop using gcc pass 2 spec and using a sed for
> 2 changes
> http://ipcop.svn.sourceforge.net/viewvc/ipcop/ipcop/trunk/lfs/gcc?revision=
> 5400&view=markup But we use gcc-4.4.5, and do not harden gcc pass 2, only
> final gcc is hardened. Like ALT-linux we use
> GCC_TOLERATE_ALWAYS_OVERFLOW=1 make check
> We use UNTESTFLAGS=\"--target_board=unix\{,-fstack-protector\}\""
> This test both the standard way and with -fstack-protector but double the
> time to run the tests.

This looks helpful. I'll try it out. Thanks.

> Why don't you use the default-format-security patch for gcc that debian and
> many others like alt-linux use?
> http://sisyphus.ru/en/srpm/Sisyphus/gcc4.4/patches/13

There is an audit planned in my to do list. Adding this patch now doesn't do 
much good unless the warnings are investigated. I plan to add that patch in 
the future. This sort of stuff should be on a roadmap.

> Hardcoding -fstack-protector-all by default make it uneasy to compile the
> kernel with -fstack-protector only.
> The kernel dev have removed the possibility to compile the kernel with
> -fstack-protector-all for those reasons :
> http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdi
> ff;h=14a3f40aafacde1dfd6912327ae14df4baf10304
> 
> Read more details of the -all overhead in this post
> http://osdir.com/ml/linux-kernel/2009-10/msg07064.html

The GCC patch could be changed so that -fstack-protector will disable -fstack-
protector-all. An alternative is "-fno-stack-protector -fstack-protector", but 
I don't think the kernel Makefile's do that.

> So, is -fstack-protector-all really a good default option?

Years ago we tried a proof of concept, using -fstack-protector-all on the 
kernel, and found that it did not stop stack overflows. An unrelated kernel 
routine caught the overflow instead. The code should be archived somewhere on 
this mailing list. I don't know if anything has changed since then.

I'm curious to see if a blatant stack overflow added to a kernel module, and 
then loaded, would cause an SSP abort, or if it would be caught by another 
kernel mechanism.

As far as using -fstack-protector-all system wide, from what I can see it is 
reasonable. The difference between a system compiled with -fstack-protector-all 
and a vanilla system is subtle. I think the push to use -fstack-protector is 
for non-hardened systems, like desktops, where performance is a bigger 
concern.

> > The idea being that GCC pass 1 is close to vanilla specs, except for
> > -fPIC. I think this idea should still work with some more tweaking.
> > There are ideas for plan B and plan C if this idea fails. It would be
> > nice to get this test suite to pass.
> > 
> > I want to convert the NetBSD test suite for libssp to use GNU make, so
> > that we can run this test suite after GCC pass 2 is installed. It's a
> > nice test suite.
> 
> Is-it related to debian patches for the test suite
> http://patch-tracker.debian.org/package/gcc-4.5
> or
> http://patch-tracker.debian.org/package/gcc-4.4

I'll look at this too next time I test GCC.

> > It tests both SSP and _FORTIFY_SOURCE. The tests included with Glibc and
> > GCC are also good, but do not assume that we enable these options by
> > default. NetBSD may or may not test for all the same functions fortified
> > by Glibc, so this needs to be verified, and extra tests added if needed.
> > There is also a paxtest package, and libsafe package, which also include
> > similar toolchain tests.
> 
> ..
> 
> > The Coreutils test suite was picky about mount options. I did get the
> > vast majority of tests to pass before... tests that would normally be
> > disabled on LFS due to missing ACL support. A note needs to be added to
> > chapter 2 about this. Extra mount options will be necessary to use posix
> > capabilities, to disable suid-root bits.
> 
> I have coreutils test suite ok with 2 fixes
> this patch is needed on ext3 or fiemap tests fail
> http://git.savannah.gnu.org/cgit/coreutils.git/commit/?id=5c3fd50a751a93acf
> 5ad7bb69d01261267a53a1e
> 
> cp/sparse-to-pipe is racy, this sed fix that
> sed -i 's/^cmp sparse copy/wait; cmp sparse copy/' tests/cp/sparse-to-pipe
> I encounter the race only in 1 of the four machines I tested.

Thank you for the helpful info.

robert
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.linuxfromscratch.org/pipermail/hlfs-dev/attachments/20110223/fb8d4d7d/attachment.sig>


More information about the hlfs-dev mailing list