stage1/xgcc -Bstage1/ -B/usr/i386-gentoo-linux-uclibc/bin/ -c -march=i386 -pipe -O2 -fprofile-generate -DIN_GCC -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -pedantic -Wno-long-long -Wno-variadic-macros -Wold-style-definition -Wmissing-format-attribute -DHAVE_CONFIG_H -I. -I. -I/var/tmp/portage/gcc-4.1.1/work/gcc-4.1.1/gcc -I/var/tmp/portage/gcc-4.1.1/work/gcc-4.1.1/gcc/. -I/var/tmp/portage/gcc-4.1.1/work/gcc-4.1.1/gcc/../include -I/var/tmp/portage/gcc-4.1.1/work/gcc-4.1.1/gcc/../libcpp/include /var/tmp/portage/gcc-4.1.1/work/gcc-4.1.1/gcc/ggc-common.c -o ggc-common.o stage1/cc1: stack smashing attack in function ix86_split_to_parts() xgcc: Internal error: Killed (program cc1) Please submit a full bug report. See <URL:http://bugs.gentoo.org/> for instructions. make[2]: *** [ggc-common.o] Error 1 make[2]: Leaving directory `/var/tmp/portage/gcc-4.1.1/work/build/gcc' make[1]: *** [stageprofile_build] Error 2 make[1]: Leaving directory `/var/tmp/portage/gcc-4.1.1/work/build/gcc' make: *** [profiledbootstrap] Error 2 my emerge --info: Portage 2.1.1 (uclibc/x86/hardened, gcc-3.4.6, uclibc-0.9.28-r0, 2.6.18-gentoo i686) ================================================================= System uname: 2.6.18-gentoo i686 Intel(R) Pentium(R) D CPU 3.00GHz Gentoo Base System version 1.12.5 Last Sync: Wed, 27 Sep 2006 11:30:01 +0000 distcc 2.18.3 i386-gentoo-linux-uclibc (protocols 1 and 2) (default port 3632) [disabled] app-admin/eselect-compiler: [Not Present] dev-java/java-config: [Not Present] dev-lang/python: 2.4.3-r1 dev-python/pycrypto: 2.0.1-r5 dev-util/ccache: [Not Present] dev-util/confcache: [Not Present] sys-apps/sandbox: 1.2.17 sys-devel/autoconf: 2.13, 2.59-r7 sys-devel/automake: 1.4_p6, 1.5, 1.6.3, 1.7.9-r1, 1.8.5-r3, 1.9.6-r2 sys-devel/binutils: 2.16.1-r3 sys-devel/gcc-config: 1.3.13-r3 sys-devel/libtool: 1.5.22 virtual/os-headers: 2.6.17-r1 ACCEPT_KEYWORDS="x86" AUTOCLEAN="yes" CBUILD="i386-gentoo-linux-uclibc" CFLAGS="-march=i386 -Os -pipe -fomit-frame-pointer" CHOST="i386-gentoo-linux-uclibc" CONFIG_PROTECT="/etc /var/bind" CONFIG_PROTECT_MASK="/etc/env.d /etc/gconf /etc/revdep-rebuild /etc/terminfo" CXXFLAGS="-Os -pipe" DISTDIR="/var/cache/distfiles" FEATURES="autoconfig buildpkg distlocks metadata-transfer nodoc noinfo noman sandbox sfperms strict" GENTOO_MIRRORS="http://distfiles.gentoo.org http://distro.ibiblio.org/pub/linux/distributions/gentoo" LINGUAS="" MAKEOPTS="-j4" PKGDIR="/var/cache/packages/default" PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --compress --force --whole-file --delete --delete-after --stats --timeout=180 --exclude='/distfiles' --exclude='/local' --exclude='/packages'" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="/usr/alpine-portage" SYNC="rsync://rsync.gentoo.org/gentoo-portage" USE="x86 X509 bitmap-fonts bri bzip2 cli cracklib dlloader dri elibc_uclibc encode expat extensions hardened input_devices_evdev input_devices_keyboard input_devices_mouse iproute2 ipv6 jpeg kernel_linux mad minimal ncurses netboot ogg oss pci pcmcia pic png pppd readline reflection rrdtool sensord session snmp speex spl ssl tdb truetype truetype-fonts type1-fonts uclibc uclibc++ udev usb userland_GNU userlocales video_cards_dummy video_cards_fbdev video_cards_v4l winbind wordexp xorg zlib" Unset: CTARGET, EMERGE_DEFAULT_OPTS, INSTALL_MASK, LANG, LC_ALL, LDFLAGS, PORTAGE_RSYNC_EXTRA_OPTS
gcc-4* is not supported (and is package.masked) on hardened profiles.
it's going to have to be fixed sooner or later; hardened cant sit in the past forever
Created attachment 98765 [details, diff] gcc-4.1.1-cc1-no-stack-protector.patch The attached patch fixes the compile error and let me compile gcc-4.1.1. Should be applied from toolchain.eclass (See http://www.mail-archive.com/gentoo-embedded@lists.gentoo.org/msg01320.html) However, when I compile, the ssp is turned off by default and when compiling with -fstack-protector I get a linker error: nc ~ # gcc -fstack-protector stacksmash.c /tmp/ccCEKul8.o: In function `smash': stacksmash.c:(.text+0x37): undefined reference to `__stack_chk_fail' collect2: ld returned 1 exit status I think its one step forward at least.
To resolve the __stack_chk_fail symbol you need glibc-2.4 (currently masked on hardened - see bug #94325). w.r.t. the stack smash in ix86_split_to_parts, I don't know what's causing that - it doesn't happen for me. See bug #149649 for hardened gcc-4.1.1 work. If you're interested, you can try the stuff in my dev overlay http://overlays.gentoo.org/dev/kevquinn - but be aware this is experimental, and the approach may change significantly (in particular, don't use it on production servers!).
Ahem - as you're using uclibc, you need a gcc-4.1 compliant version of that (telling you to use glibc-2.4 isn't helpful ;) ). I don't know the status of uclibc in Gentoo for gcc-4.1 - I believe psm is the expert there so CC'ing for him to comment.
(In reply to comment #5) > Ahem - as you're using uclibc, you need a gcc-4.1 compliant version of that > (telling you to use glibc-2.4 isn't helpful ;) ). I don't know the status of > uclibc in Gentoo for gcc-4.1 - I believe psm is the expert there so CC'ing for > him to comment. I have (non-hardened) uclibc with gcc-4.1.1 running here.
the failure happens (and iirc is not dependent on glibc/uclibc), if hardened compiler is used to build a non-hardened one (and there are other possibilities as well, can't recall them all). toolchain.eclass applies a patch, the comment there has to be extended/generalized and the patch has to be ported to 4.0.x and 4.1.x - they are different - I have them for the case gcc-4.1.x becomes reality, the patch makes cc1 been compiled without -fssp (the stack smashing happens in this function if gcc-3.4.x is used to build a new compiler, if you have gcc-4.x hardened already and you try to rebuild gcc (even hardened one), the failure happens in ggc-common.o instead of timevar.o.
(In reply to comment #6) > (In reply to comment #5) > > Ahem - as you're using uclibc, you need a gcc-4.1 compliant version of that > > I have (non-hardened) uclibc with gcc-4.1.1 running here. By "4.1-compliant" I mean that you need a version of uclibc that includes definitions for __stack_chk_fail (and __stack_chk_fail_local) - > nc ~ # gcc -fstack-protector stacksmash.c > /tmp/ccCEKul8.o: In function `smash': > stacksmash.c:(.text+0x37): undefined reference to `__stack_chk_fail' > collect2: ld returned 1 exit status shows that you have a version of uclibc that doesn't.
Ah; thanks for the clues, Peter :) My current approach to gcc-4.1.1 itself doesn't build gcc hardened, so that's why I haven't seen it.
hmm; I wonder if moving the declarations: long l[4]; (of which there are two, one for x86 and one for amd64) to the beginning of the function instead of inside the blocks might make the stack smash disappear. We've seen corruption of the stack with gcc-3.x with this sort of thing (see bug #133301 in particalar, but also others referenced on bug #135265). We see it with C++ rather than C, but I think that's because the internal declaration syntax is a C++ concept, using it in C is a GCC extension.
only uClibc-svn supports gcc-4.1-style ssp
(In reply to comment #10) > hmm; I wonder if moving the declarations: > > long l[4]; > > (of which there are two, one for x86 and one for amd64) to the beginning of the > function instead of inside the blocks might make the stack smash disappear. Isn't a stack smash a logical bug in the the code? reordering vars sounds like the bug overwrites other variables (in stack) instead of overwriting the canary value. > > We've seen corruption of the stack with gcc-3.x with this sort of thing (see > bug #133301 in particalar, but also others referenced on bug #135265). We see > it with C++ rather than C, but I think that's because the internal declaration > syntax is a C++ concept, using it in C is a GCC extension. >
(In reply to comment #12) > (In reply to comment #10) > > hmm; I wonder if moving the declarations: > > > > long l[4]; > > > > (of which there are two, one for x86 and one for amd64) to the beginning of the > > function instead of inside the blocks might make the stack smash disappear. > > Isn't a stack smash a logical bug in the the code? Normally, yes. However with 3.x at least we suspect strongly that there's a bug in the compiler - the issue on bug #133301 is present on vanilla compilers as well (just doesn't get caught by ssp in that case, obviously). On #133301, moving the declarations to the top of the function caused the compiler to generate correct code.
Created attachment 98814 [details, diff] toolchain.eclass diff for gcc-4.1 hardened my eclass diff (works only with uClibc-svn), but shows what I do to support gcc-4 hardened
Created attachment 98815 [details] gcc-3.4.6 new style piessp patch
Created attachment 98816 [details] gcc-4.1.x piessp patch , new style the gcc-4.1.x could fail in vanilla gentoo environment, because I use uclibc backported patches instead of the gentoo provided ones
Created attachment 98817 [details] gcc-4.2.x piessp patch
Created attachment 98818 [details] my mini and maxi specs to be used with 9.0.3 piepatches
Created attachment 98819 [details, diff] disable TLS use for SSP on uClibc
Created attachment 98820 [details, diff] enable __stack_chk_guard in libc for uClibc (only svn) Quick hack to enable ssp in libc on uClibc (only usable with uClibc-svn), we should probably add a real check
additionally 51_all_gcc-3.4-libiberty-pic.patch is not enough and obsoleted by sed -i 's:^PICFLAG =:PICFLAG = -fPIC:' ${S}/libiberty/Makefile.in needed for all gcc4 versions since 4.0.0, else using a hardened compiler will create imtermediate executables for stage1 that have textrels (and this could fail if the support for textrels is disabled in libc and/or PaX), caused by compiling objects in libiberty.a with -fPIE instead if -fPIC
(In reply to comment #11) > only uClibc-svn supports gcc-4.1-style ssp > So we are all waiting for uclibc-0.9.29 to come around? I pinged the uclibc list earlier this morning.
thanks for those, Peter - could you post also the gcc-*-cc1-no-stack-protector.patch files?
the gcc-4.1.1-cc1-* patch posted by Natanael Copa is correct, works with gcc-4.0.x and 4.1.1 (I was wrong that they differ, the one for gcc-4.2 differs, if you want that, I attach it too)
ok thanks; the 4.1.1 patch is enough for now. I found I had to tweak upstream/03_all_gcc-4.1.0-v9.0.1-pie-arm.patch for gcc-4.1.1 - the macro name LINUX_DYNAMIC_LINKER has changed to LINUX_TARGET_INTERPRETER.
that is due to the fact, that I use the uclibc backported patch
this bug contains good information useful for porting gcc-4.x to hardened specs. Thanks all, Alex
I'am working on hardened gcc 4 toolchain What is needed to get ssp/pie support whit uclibc?
(In reply to comment #28) > I'am working on hardened gcc 4 toolchain > What is needed to get ssp/pie support whit uclibc? > IIRC, either upgrade to uclibc-0.9.29 or backport the __stack_chk_guard function (and _dl_setup_stack_chk_guard I suppose)
(In reply to comment #29) > (In reply to comment #28) > > I'am working on hardened gcc 4 toolchain > > What is needed to get ssp/pie support whit uclibc? > > > > IIRC, either upgrade to uclibc-0.9.29 or backport the __stack_chk_guard > function (and _dl_setup_stack_chk_guard I suppose) > Okey will wait for .29 in portage.
(In reply to comment #30) > (In reply to comment #29) > > (In reply to comment #28) > > > I'am working on hardened gcc 4 toolchain > > > What is needed to get ssp/pie support whit uclibc? > > > > > > > IIRC, either upgrade to uclibc-0.9.29 or backport the __stack_chk_guard > > function (and _dl_setup_stack_chk_guard I suppose) > > > Okey will wait for .29 in portage. > uclibc 0.9.30 is out.
Can we add gcc-4-stack-protector-uclibc-no-tls.patch to uclibc patchset for gcc version >=4.3.2? Thanx for testing Natanael Copa and can you add the pt_gnu_eh_frame patch? Witch version will the pt_gnu_eh_frame be fixed in? Make a bug on that? We don't depend on bug 182094 any longer 0.9.30 is in portage with ssp support.
Created attachment 173413 [details, diff] pt_gnu_eh_frame.patch the requested patch. This thread: http://gcc.gnu.org/ml/gcc-patches/2006-06/msg00780.html might be of interest.
I have no idea if this is still an issue.
Created attachment 200600 [details, diff] Update of gcc4-stack-protector-uclibc_no_tls.patch for more arch support Thanx for the update ncopa and i think it will fix bug #267335
Created attachment 200602 [details] Update of gcc4-stack-protector-uclibc_no_tls.patch for more arch support sorry did forget .patch
gcc-4.X SSP support with glibc in the tree now gcc-4.X SSP support with uclibc will be supported when it get tls, nptl support and i will open new bug for that.