On Tuesday 22 February 2011 13:12:43 you wrote: > Selon Robert Connolly <rob...@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
signature.asc
Description: This is a digitally signed message part.
-- http://linuxfromscratch.org/mailman/listinfo/hlfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
