gcc-3.3.5-r1 generates macro definitions __SSP__ and __SSP_ALL__, which are set if -fstack-protector and -fstack-protector-all are set respectively. So do the 3.4.3 compilers. gcc-3.3.5-20050130-r1 does not do so (nor does gcc-3.3.5-20050130-r2; haven't tried gcc-3.3.5-20050130). This causes flag-o-matic to fail for hardened systems which switch SSP on via the specs file. Specifically: filter-flags -fstack-protector fails to recognise that gcc has the stack protector engaged. Looks to me like a regression in the ssp patch.
# emerge info Portage 2.0.51.19 (default-linux/x86/2005.0, gcc-3.3.5, glibc-2.3.4.20050125-r1, 2.6.11-hardened-r1 i686) ================================================================= System uname: 2.6.11-hardened-r1 i686 AMD Athlon(tm) XP 3200+ Gentoo Base System version 1.4.16 Python: dev-lang/python-2.3.5 [2.3.5 (#1, Apr 28 2005, 03:44:02)] ccache version 2.3 [enabled] dev-lang/python: 2.3.5 sys-apps/sandbox: [Not Present] sys-devel/autoconf: 2.59-r6, 2.13 sys-devel/automake: 1.7.9-r1, 1.8.5-r3, 1.5, 1.4_p6, 1.6.3, 1.9.5 sys-devel/binutils: 2.15.92.0.2-r7 sys-devel/libtool: 1.5.16 virtual/os-headers: 2.6.11 ACCEPT_KEYWORDS="x86" AUTOCLEAN="yes" CFLAGS="-march=athlon-xp -pipe -O2" CHOST="i686-pc-linux-gnu" CONFIG_PROTECT="/etc /usr/kde/2/share/config /usr/kde/3.3/env /usr/kde/3.3/share/config /usr/kde/3.3/shutdown /usr/kde/3/share/config /usr/lib/X11/xkb /usr/lib/mozilla/defaults/pref /usr/share/config /var/qmail/control" CONFIG_PROTECT_MASK="/etc/gconf /etc/terminfo /etc/env.d" CXXFLAGS="-march=athlon-xp -pipe -O2" DISTDIR="/usr/portage/distfiles" FEATURES="autoaddcvs autoconfig buildpkg ccache distlocks fixpackages sandbox sfperms strict userpriv" GENTOO_MIRRORS="http://linux.rz.ruhr-uni-bochum.de/download/gentoo-mirror/ http://ftp.linux.ee/pub/gentoo/distfiles/ http://ftp.easynet.nl/mirror/gentoo/ http://ftp.heanet.ie/pub/gentoo/" LINGUAS="en-gb en de es it fr" MAKEOPTS="-j2" PKGDIR="/var/lib/portage/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="/var/portage" SYNC="rsync://rsync.gentoo.org/gentoo-portage" USE="x86 3dnow X aalib acl acpi alsa apm arts audiofile avi berkdb bidi bitmap-fonts cdparanoia cdr crypt cups curl dhc-fqdn directfb dlloader doc dvb dvd dvdr eds emboss encode esd faad fam fbcon ffmpeg flac font-server foomaticdb fortran gcj gd gdbm gif gnome gpm gstreamer gtk gtk2 guile hardened imagemagick imlib ipv6 java javamail jce jikes jpeg junit kde kdeenablefinal kerberos ldap libg++ libwww mad maildir mbox mikmod mmx motif mozilla mp3 mpeg mpeg4 multitarget mysql ncurses nls nptl odbc ogg oggvorbis opengl oss pam pdflib perl pic pie png postgres python qt quicktime readline ruby samba sasl sdl slang slp speex spell sse ssl svgatcltk tcpd tiff truetype truetype-fonts trusted type1-fonts unicode usb v4l v4l2 vorbis wifi wxwindows xinexinerama xml2 xmms xosd xprint xv xvid zlib linguas_en-gb linguas_en linguas_de linguas_es linguas_it linguas_fr userland_GNU kernel_linux elibc_glibc" Unset: ASFLAGS, CBUILD, CTARGET, LANG, LC_ALL, LDFLAGS
Just to confirm, this is because the stack protector tarball protector-3.3.5.20050130-1.tar.gz doesn't include the relevant changes. The changes are present in older protector-3.3.2-3.tar.gz, and also in the newer protector-3.4.1-1.tar.gz, protector-3.4.3-0.tar.gz and protector-3.4.3.20050110-0.tar.gz that I have in my distfiles. In other words, gcc-3.4.3-20050110 and gcc-3.4.4 are ok.
Upping severity; apps known to crash with ssp will ignore 'filter-flags -fstack-protector' when built with 3.3.5-20050130*. I'll look into updating flag-o-matic to cope.
Kevin, what changes were dropped with the protector-3.3.5.20050130-1.tar.gz tarball?
Well, the two tarballs have quite a few differences. The difference that matters most here is to gcc/c-common.c, where this diff block (from the 3.3.2-3 tarball protector.dif): Index: gcc/c-common.c =================================================================== RCS file: /home/cvsroot/gcc/gcc/c-common.c,v retrieving revision 1.1.1.11 retrieving revision 1.1.1.11.4.1 diff -c -3 -p -r1.1.1.11 -r1.1.1.11.4.1 *** gcc/c-common.c 2003/10/22 02:21:19 1.1.1.11 --- gcc/c-common.c 2004/09/03 04:51:44 1.1.1.11.4.1 *************** cb_register_builtins (pfile) *** 4998,5003 **** --- 4998,5009 ---- if (flag_objc && flag_next_runtime) cpp_define (pfile, "__NEXT_RUNTIME__"); + /* Make the choice of the stack protector runtime visible to source code. */ + if (flag_propolice_protection) + cpp_define (pfile, "__SSP__=1"); + if (flag_stack_protection) + cpp_define (pfile, "__SSP_ALL__=2"); + /* A straightforward target hook doesn't work, because of problems linking that hook's body when part of non-C front ends. */ # define preprocessing_asm_p() (cpp_get_options (pfile)->lang == CLK_ASM) is just not present in the 3.3.5.20050130-1 tarball (protector.dif). However I wouldn't suggest patching the above into the 3.3.5.20050130-1 version since there are a lot of other differences. Unfortunately I can't see an obvious patch version (other than the name of the tarball) so I don't know if perhaps an older version of the stack protector made it into 3.3.5.20050130-1. The definition of __SSP__ and __SSP_ALL__ were a relatively recent addition to the ssp patch. It may be that the defintions were back-ported to the 3.3.2 and not 3.3.5.20050130-1; since distfiles doesn't have a CVS history it's impossible to tell unless someone remembers. However I still have the 3.3.2-2 tarball which doesn't contain the __SSP__ definitions, so they went in to 3.3.2-3 sometime between Nov 8 2004 and Jan 15 2005 (if my file dates are to be believed). I don't know where some of the patch balls have come from; the 3.3.2-3 and 3.4.1-1 tarballs are available on http://www.research.ibm.com/trl/projects/security/ssp/ but the others are obviously sourced via a different route - I'd previously assumed they all came from the same place. BTW the tweak I made to flag-o-matic today (and additions to toolchain-funcs - ref bug #100974) should remove our dependency on the __SSP__ and __SSP_ALL__ definition. I'm wary of messing around with the SSP patches, so perhaps it's best to leave it alone...
i think the updated ssp patches came from pappy/lv either way you can find them in cvs now ... gentoo/src/patchsets/gcc/<ver>/ssp/ update those files as you see fit before moving them to mirrors/ebuilds
Looks like this is fixed for the now stable version of gcc.
Should have posted something here - I added the relevant bits to the gcc-3.3.6 ssp patchset, so if you ever rebuild them again it'll be fixed there as well.
