HEADS UP: static libraries and FORTIFY_SOURCE
Thor Lancelot Simon <tls <at> rek.tjls.com>
2007-05-29 22:02:21 GMT
[Apologies for not giving more notice/warning about turning on
FORTIFY_SOURCE for some system libraries at the time of my commit; it's
clear to me now that the implications for 3rd-party code were considerably
greater than I mistakenly expected]
A few days ago, I turned on the "fortify source" (argument length checking
on memory and string copy and set functions) for those system libraries
which handle network data or have a history of data-driven bugs (or, of
course, in many cases, both). For various technical reasons I didn't
turn it on for libc, but this didn't limit the scope of the resulting
inter-library dependencies on libssp as much as one might think.
For dynamic libraries, the dependencies don't cause any problem: they
are automatically handled by the runtime linker. But for programs that
are statically linked to a library which was built with FORTIFY_SOURCE,
this imposes a requirement to link to libssp. This kind of implicit
dependency between static libraries is one reason an increasing number
of Unixy operating systems have deprecated static linkage, but though
NetBSD links the whole system static by default, that would be a rather
dramatic step to take at this time.
The issue shows up most obviously as undefined symbols in programs in
pkgsrc that build with -static (though they often don't need to).
After examining the problem at a bit more length I think the right
solution is to move the FORTIFY_SOURCE support we currently have in
libssp into libc. The increase in size of the dynamic libc will be
approximately 8 kilobytes, and, of course, static programs that don't
use the functions in question won't grow at all.