On Fri, Jan 27, 2012 at 10:00:53AM -0800, Russ Allbery wrote: > Russ Allbery <r...@debian.org> writes: > > "Cantor, Scott" <canto...@osu.edu> writes: > > >> Not that it's necessarily likely here, but with the --silent flag on to > >> limit noise, you actually can't tell what the actual compiler command > >> is. There are libtool bugs, usually on Solaris one finds, that break > >> the use of some flags. I guess it's possible something like that could > >> be happening. > > > True. Okay, let me go do a manual build where I can remove --silent and > > be sure that things are actually being passed down to the compiler. > > Without --silent, libtool definitely claims to be sending that flag: > > /bin/bash ../libtool --tag=CXX --mode=compile g++ -DHAVE_CONFIG_H -I. -I.. > -pthread -g -Wall -O2 -O2 -DNDEBUG -D_FORTIFY_SOURCE=2 -pthread -Wall -g > -O2 -fstack-protector --param=ssp-buffer-size=4 -Wformat -Wformat-security > -Werror=format-security -O2 -DNDEBUG -c -o AbstractComplexElement.lo > AbstractComplexElement.cpp > libtool: compile: g++ -DHAVE_CONFIG_H -I. -I.. -pthread -g -Wall -O2 -O2 > -DNDEBUG -D_FORTIFY_SOURCE=2 -pthread -Wall -g -O2 -fstack-protector > --param=ssp-buffer-size=4 -Wformat -Wformat-security -Werror=format-security > -O2 -DNDEBUG -c AbstractComplexElement.cpp -fPIC -DPIC -o > .libs/AbstractComplexElement.o > > and I suspended the build in the middle of compiling a source file, and > that flag is there in the process arguments: > > eagle 9987 0.0 0.0 2088 512 pts/10 T 09:54 0:00 g++ > -DHAVE_CONFIG_H -I. -I.. -pthread -g -Wall -O2 -O2 -DNDEBUG > -D_FORTIFY_SOURCE=2 -pthread -Wall -g -O2 -fstack-protector > --param=ssp-buffer-size=4 -Wformat -Wformat-security -Werror=format-security > -O2 -DNDEBUG -c AbstractComplexElement.cpp -fPIC -DPIC -o > .libs/AbstractComplexElement.o > > but hardening-check returns the same result: > > windlord:~/dvl/debian/xmltooling> hardening-check > xmltooling/.libs/libxmltooling.so > xmltooling/.libs/libxmltooling.so: > Position Independent Executable: no, regular shared library (ignored) > Stack protected: yes > Fortify Source functions: no, no protected functions found! > Read-only relocations: yes > Immediate binding: no not found! > > so if there's a failure here, it seems to be somewhere inside g++, or a > need to include more than just -D_FORTIFY_SOURCE=2 to enable this.
Hmm, I'm not sure what's wrong here. I'm adding Kees Cook to CC. Kees, did you see similar issues with C++ on Ubuntu when g++ was patched to use FORTIFY_SOURCE by default? This is http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=656656 > (Moritz, do you know if bindnow is safe for shared libraries? I know pie > isn't, since it conflicts with PIC, but I've only been omitting bindnow > because I wasn't sure. I'm not concerned with the possible performance > issues; startup cost isn't significant for the known users of these > libraries.) It should be safe. It only slightly increases the startup time, since all symbols need to be resolved. Cheers, Moritz -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org