toolchain stuff (and libsafe)

Robert Connolly robert at
Thu May 31 11:33:52 PDT 2007

I got Glibc building protected programs using only the configparms file, and 
no patches (except the -fno-stack-protector Sed command for ./configure). I 
didn't try the test suite yet. There is one minor ugliness... when building 
the library half of Glibc in nscd/, _FORTIFY_SOURCE is redefined from what is 
in configparms to what nscd/Makefile sets. This causes about a dozen 
warnings, but is otherwise harmless.

All the 'ignoring return value' warnings from Binutils have been fixed in 
Binutils CVS, and I added a patch for that. None of the warnings for GCC have 
been fixed upstream. I also backported the patch for -Wno-overlength-strings 
to get rid of the "string length `WHATEVER' is greater than the length `509'" 
warnings in fixincludes/. I made a patch for the GCC warnings, but I need to 
make sure a kernel can be built with it. The patch uses simple if's instead 
of assert. It shouldn't be long before binutils and gcc can build 
with --enable-werror-always again.

I would like to add either LibsafePlus or Libsafe to chapter 6. LibsafePlus 
does a better job than Libsafe, by using another utility called TIED to 
reconstruct programs and libraries to emit buffer size information for the 
LibsafePlus library. The library checks data size verses buffer size before 
filling the buffer, to be sure there is enough room for the data, and exit's 
the program otherwise. It does not protect all function, just the more 
dangerous ones. For performance both LibsafePlus and Libsafe support an 
option, set in /etc/libsafe.exclude, where only processes with a userid lower 
than 100 (or whatever) will be protected.

The LibsafePlus/TIED package is fairly intrusive to implement. Each program 
and library needs to be reconstructed. Without doing this LibsafePlus will 
behave exactly like Libsafe. The major difference between LibsafePlus and 
Libsafe is that LibsafePlus's checking is much more precise. The runtime 
performance is almost the same.

In theory the _FORTIFY_SOURCE checking is supposed to do the same thing as 
Libsafe, but it doesn't. _FORTIFY_SOURCE was designed to sacrifice some 
checking for performance. In the Libsafe/LibsafePlus exploits/ directory 
there is a 'canary-exploit' printf overflow which is _not_ killed by ssp or 
fortify_source. I'm running a lightly configured grsecurity kernel, and it's 
not killed by PaX either.

LibsafePlus can also be installed in chapter 7 because it modifies binaries, 
and the library is preloaded. Installing it in chapter 6 will detect problems 
earlier, but will make the builds in chapter 6 slower. It is fairly 
configurable, in that we can choose which programs and user-ids get 
protection, and which programs get full (TIED) protection.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <>

More information about the hlfs-dev mailing list