I can build a "hello world" startup program statically; usually it is about 4K. Now it is 400K and running it segfaults. I am not aware of changing anything -- not libs or gcc or source -- nothing. Something obviously changed... The first time I started seeing this, I suspected instability of GCC 3.3.1, which I had used to build my system, so I built a clean Gentoo box all over again. And it worked fine for a few weeks. Now bug is back, with gcc-3.2.3-r1 I will post source of problem file as attachment. Reproducible: Always Steps to Reproduce: gcc --version 3.2.3 20030422 (Gentoo Linux 1.4 3.2.3-r1, propolice)
Created attachment 15065 [details] Test case file intended to be used in a boot initrd envrionment gcc -static -nostartfiles -pipe helloworld.c -o helloworld Expected value: A 4kb executable that prints a message if running as PID != 1 Actual value: A 410+ kb executable that prints a not-so-nice "Segmentation fault" If you compile this without the -static flag, it will work fine. But I need it to work with static.
Created attachment 15066 [details] Test case file intended to be used in a boot initrd envrionment gcc -static -nostartfiles -pipe helloworld.c -o helloworld Expected value: A 4kb executable that prints a message if running as PID != 1 Actual value: A 410+ kb executable that prints a not-so-nice "Segmentation fault" If you compile this without the -static flag, it will work fine. But I need it to work with static.
Well... my bug might be expected behaviour... I am in the process of RT'ing the FM at http://www.muppetlabs.com/~breadbox/software/tiny/teensy.html ... particularly the part that says that returning from _start will segfault. Cool! Only: why did it work before? Still not certain if this is a bug or not. (gentoo linux: a way to constantly bump into things you forgot about computing)
Strange, no error here. $ gcc -static -nostartfiles -pipe helloworld.c -o helloworld helloworld.c: In function `wrInt': helloworld.c:85: warning: passing arg 2 of `itoa' from incompatible pointer type $ ./helloworld ZAMBOCOM welcomes YOU who have FOUND ZAMBOCOM!! YAR! PID != 1!! 0000020878 $ ls -la total 13 drwxr-xr-x 2 lowzl users 1024 Jul 27 17:34 . drwxr-xr-x 15 lowzl users 1024 Jul 27 17:32 .. -rwxr-xr-x 1 lowzl users 6557 Jul 27 17:34 helloworld -rw------- 1 lowzl users 3143 Jul 27 17:32 helloworld.c $ file helloworld helloworld: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), statically linked, not stripped $ gcc -v Reading specs from /usr/lib/gcc-lib/i686-pc-linux-gnu/3.2.3/specs Configured with: /var/tmp/portage/gcc-3.2.3-r1/work/gcc-3.2.3/configure --prefix=/usr --bindir=/usr/i686-pc-linux-gnu/gcc-bin/3.2 --includedir=/usr/lib/gcc-lib/i686-pc-linux-gnu/3.2.3/include --datadir=/usr/share/gcc-data/i686-pc-linux-gnu/3.2 --mandir=/usr/share/gcc-data/i686-pc-linux-gnu/3.2/man --infodir=/usr/share/gcc-data/i686-pc-linux-gnu/3.2/info --enable-shared --host=i686-pc-linux-gnu --target=i686-pc-linux-gnu --with-system-zlib --enable-languages=c,c++,ada,f77,objc,java --enable-threads=posix --enable-long-long --disable-checking --enable-cstdio=stdio --enable-clocale=generic --enable-__cxa_atexit --enable-version-specific-runtime-libs --with-gxx-include-dir=/usr/lib/gcc-lib/i686-pc-linux-gnu/3.2.3/include/g++-v3 --with-local-prefix=/usr/local --enable-shared --enable-nls --without-included-gettext Thread model: posix gcc version 3.2.3 20030422 (Gentoo Linux 1.4 3.2.3-r1, propolice)
Right! Zhen Lin's results are much like what I got up until two days ago. This is the second time this has happened on this system: the compile working, then not working... I suspect some oddness with binutils and new kernel. Trying to track it down... I am bootstrapping a "clean" gentoo system at the moment...
Ok, if you can track it, it will be appreciated - gcc-3.3 here with kernel-2.6 and glibc-2.3.2 (not so old CVS) and NPTL, so going back to your setup will take some time.
Martin: The configuration that you mention is very similar to mine: glibc-2.3.2 with NPTL, kernel 2.6... I am in the process of building up a "clean" system, I'm in stage2, I've emerged a GCC-3.3-r1, and it does NOT exhibit this bug! Which is what I expected. I think that an ldconfig gets b0rked somewhere... I don't think this is strictly a GCC bug...
OK... 1) build a base system 2) install gcc with propolice 3) build a gcc (3.3,propolice) with the gcc from #2 4) build a glibc (2.3.2-r3, propolice) with the gcc from #3 5) build the tiny app -static with gcc from #3 -- and you get lots of linkage errors: libgcc.a: In function '__stack_smash_handler': (undefined reference to strncat, blah blah blah) This is NOT the same problem, of course. But you see where this might be leading... The creation of compiler (step #3) was NOT in a bootstrap phase, and I didn't have 'static' in my USE flags... I am now at step 6 -- what do I do next? Normally, after a glibc re-install, I would "emerge -e --deep world". But before I do that -- Seems that I should re-install GCC with 'static' in USE. But maybe I should just run bootstrap again... I will try (re) building gcc with 'static' in USE. GCC has it's own "boostrap" process, anyhow. After that, we will see... late. I go home now.
I cannot build ANY static binaries now! # cat > tiny.c int main() {return 42;} # gcc -static -fno-stack-protector tiny.c -o tiny /usr/lib/gcc-lib/i686-pc-linux-gnu/3.3/libgcc.a(_stack_smash_handler.oS)(.text+0xd9): In function '__stack_smash_handler': . . . Lots of errors. I suggest that we add stack-protector to stripped flags.
I can build static binaries against another libc; I installed uClibc-0.9.20: # emerge uclibc # /usr/i386-linux-uclibc/usr/bin/gcc -static -fno-stack-protector tiny.c -o tiny # ./tiny # echo $? 42 # md5sum tiny 509c38580519450fc20205e5fc976608 tiny This uses a wrapper around gcc that links against uClibc instead of glibc.
Original test case file compiles against uClibc wrapper: # /usr/i386-linux-uclibc/usr/bin/gcc -static -fno-stack-protector helloworld.c -o helloworld -nostartfiles # ./helloworld ZAMBOCOM welcomes YOU who have FOUND ZAMBOCOM!! YAR! PID != 1!! 0000002007 Renaming this bug to "ProPolice-enabled glibc will confuse the static linker..."
Second attempt: 1) build a base system 2) install gcc with propolice 3) build a gcc (3.3,propolice) with the gcc from #2 4) build a glibc (2.3.2-r3, WITHOUT propolice) with the gcc from #3 5) build the tiny app -static with gcc from #3 This *works* -- no crashing, no large broken test cases -- and the ONLY difference here seems to be that we are building glibc WITHOUT "-fstack-protector" in CFLAGS of /etc/make.conf When I say "build a base systems", I mean to boostrap a system from a gentoo 1.4 stage1 CD. continuing this test... 6) build a glibc 2.3.2-r3 WITH propolice enabled (-fstack-protector) 7) compile test cases ... and it is once again impossible to build the test cases, cannot satisfy links to stack_smash_handler support functions. It is impossible to test the original bug in the presence of propolice stack protection enabled in glibc. 8) emerge binutils gcc 9) compile test cases This CORRECTS the problem of the test case 1 (helloworld "zambocom"): the test case that defines _start() and compiles with -nostartfiles This DOES NOT CORRECT the problem of tiny.c -- int main() {return 42;} -- which you compile with "gcc -static" -- this still fails to link.
Frogger - word from the propolice guys maybe ?
OK, sorry, but there are essentially TWO bugs here: 1) the original one, the large b0rken app when compiling with static, and 2) the later app, which is my discovery of propolice/glibc complications with static compilation It is true that bug 2) is important -- we need to be careful about stack-protector and glibc if this is indeed a problem for other people with static compilation -- but I'd like to re-visit bug 1)... I developed a test system, a stage1 gentoo install, a bootstrap.sh system with gcc-3.3-r1 (recent propolice) and glibc 2.3.2-r1 on ~x86. This collection of software isn't bootable, but is does provide a bash shell that can run "emerge system". This stage1 test system's gcc (3.3-r1) can compile and link the static test cases discussed in this bug. Forget ProPolice for a moment; don't use -fstack-protector in the CFLAGS at all. And then emerge glibc-2.3.2-r3 (recent NPTL) and try to compile the test cases again. You get the bug: a large ELF binary that segfaults, rather than a small one that does what you expect. (note that "emerge glibc" will emerge the dependencies, among them, binutils. I am in the process of starting with a bare stage1 test system and running "ebuild glibc-2.3.2-r3.ebuild compile install qmerge" -- that is, without the intervening dependencies (except kernel sources) -- and we shall see if the bug appears...)
I am beginning to think that the original bug of large, broken static binaries from gcc -static is due to unstable version of NPTL in glibc-2.3.2-r3 I want to break this bug report into two bugs: one that is the "ProPolice/gcc -static" and another that is "broken binaries with new glibc/NPTL".
*** Bug 25720 has been marked as a duplicate of this bug. ***
*** Bug 26752 has been marked as a duplicate of this bug. ***
I've verified this, and it seems that -static does break on a propolice patched gcc, regardless of whether -fstack-protector is set. I haven't had a chance to test the effects of compiling glibc with/without -fstack-protector however, but either way something is broken. I've sent an email to Hiroaki Etoh (ProPolice author), and hopefully he will be able to advise on a solution to the problem.
Here is Hiroaki Etoh's response explaining why this happens. I tend to agree that we need to move the protector symbols to libc as shared library as a long term solution. However, as a temporary solution, I recommend we go with option 2 (as discussed below) as it requires only a trivial patch to gcc. "the default library link sequence of gcc is libgcc, libc, and libgcc. if your program has a reference to __guard, it is resolved by the first libgcc. _guard has a reference to several functions ( _sigfilset, _sigdelset, etc) and is resolved by the second libc. For the tiny.c case, there is no use of _guard, but some objects in libgcc are used. Those objects have a reference to _guard, which is resolved by the third libgcc. BUT, _sigfilset can not be resolved because the next libc is not specified. There are two options for fixing this problem. 1. moves the protector-related symbols to libc from libgcc. (_guard and _stack_smash_handler) openbsd chose this option. 2. changes the default library link sequence with libgcc, libc, libgcc, and libc. to do this, you may modify the variable LINK_GCC_C_SEQUENCE_SPEC in the gcc.c file like: #define LINK_GCC_C_SEQUENCE_SPEC "%G %L %G %L" I did it for the FreeBSD 4.3 patch. I recommen the option 1. And you can change the _stack_smash_handler based on your security policy. Hiroaki Etoh, Tokyo Research Laboratory, IBM Japan"
I am not so sure I agree about this (going with 2, and then changing to 1), as it will get hairy when we want to change (going to be difficult to guarentee not gettin linking issues due to duplicate symbols). Rather do it properly with new versions of gcc/glibc (glibc-2.3.2-r3 and gcc-3.3.1 ...). Comments ?
Excellent! How do we "move the protector symbols to libc as shared library"? I'd like to help...
Actually, how sure are we about this ? I could always compile static binaries, they were big, but worked ... and after mergeing gcc without propolice, and then ever remerging glibc/binutils, I still get: $ gcc --version; gcc -static -o foo foo.c; ls -l foo gcc (GCC) 3.3.1 20030815 (Gentoo Linux 3.3.1-r1) Copyright (C) 2003 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. -rwxr-xr-x 1 azarah azarah 487989 Aug 22 23:11 foo
GCC-3.3.1-r1 seems to fix the segfault-with-NPTL-in-static-binaries. I would like to help fix the propolice/static problem. We need to move the protector symbols to libc as shared library. Ideas?
Well, sombody will have to create a patch to integrate the symbols into glibc. This is first biggy - then we need to figure out how to get it into the tree without breaking things too much.
these patches have been created, however, the problem with -nostdlib and -fstack-protector persists: whenever -nostdlib is used, -fstack-protector should be filtered in the ebuild or in the gcc or in the respective gcc specs file if possible. another possible solution i need help with is creating a local object and a local function in binutils/ld which gets emitted into a -static binary that is linked -nostdlib when the glibc dependent __guard_setup and __stack_smash_handler which exist either in glibc or libgcc cannot be used. i have no knowledge of binutils/ld where to do this, i only know it must be done inside the emitting of functions into static binaries but these dummy nonglibc __guard_setup and __stack_smash_handler and __guard may only be emitted into static binaries and only if -nostdlib is used. Hope this helps, Alex
09:48:16 <@solar> peep this out. I just did a emerge system today. I have -fstack-protector in my CFLAGS,hgcc not installed and I was getting sizeof _stack_smash_handler changed in libgcc.a from like 700 to 400 then it bombed out. 09:48:21 <@solar> this was on modutils 09:49:43 <@mboman> hi solar! 09:49:51 <@solar> hi mboman 09:49:52 <@mboman> do you mind me stealing barnyard from you? 09:50:59 <@mboman> (net-analyzer/barnyard) 09:51:27 * solar was not aware he had such package 09:51:30 <@pappy-> solar: readelf -s /lib/libc grep guard 09:51:52 <@pappy-> solar: i bet it is insmod.static 09:52:29 <@solar> on 757: 00131020 32 OBJECT GLOBAL DEFAULT 19 __guard@@GLIBC_2.3.2 09:52:29 <@solar> 923: 00016010 144 FUNC GLOBAL DEFAULT 11 __guard_setup@@GLIBC_2.3.2 09:52:29 <@solar> 4482: 00135ec0 4 OBJECT LOCAL DEFAULT 27 authnone_private_guard 09:52:29 <@solar> 7382: 00131020 32 OBJECT GLOBAL DEFAULT 19 __guard 09:52:29 <@solar> 7548: 00016010 144 FUNC GLOBAL DEFAULT 11 __guard_setup 09:52:41 <@pappy-> solar: yes, that is it 09:52:52 <@solar> thats looks right to you? 09:53:00 <@pappy-> solar: now check the gcc line where it bombed out, is it static compiling 09:53:16 <@pappy-> that looks like the corpus delicti 09:53:30 * solar would have to recompile with -fstack enabled.. 09:53:31 <@solar> sec. 09:53:34 <@pappy-> the glibc contains the propolice functions now 09:55:37 <@solar> so two "system" in it's current state provides the symbols in two places? Is this intended? 09:55:44 <@solar> /usr/lib/gcc-lib/i686-pc-linux-gnu/3.3.2/../../../libc.a(ssp.o)(.data+0x0): multiple definition of `__guard' 09:55:52 <@solar> /usr/lib/gcc-lib/i686-pc-linux-gnu/3.3.2/libgcc.a(_stack_smash_handler.oS)(.bss+0x0):/var/tmp/portage/gcc-3.3.2-r2/work/gcc-3.3.2/gcc/libgcc2.c:2021: first defined here 09:56:08 <@pappy-> do you compile it static? 09:56:18 <@solar> newp 09:56:31 <@pappy-> but isnt it a gcc -static line that forces this 09:56:36 <@pappy-> there must be static somewhere 09:57:17 <@pappy-> i know that modutils builds insmod.static 09:57:28 <@solar> but your right.. it is insmod.static 09:57:59 <@solar> oh ok so thats the standard propolice and -static dont play along bug. this happens when libgcc still contains the guard symbols it is advisable to emerge glibc and gcc with both patches active, Martin otherwise -static compiles will fail again! thanks, Alex
> this happens when libgcc still contains the guard symbols > > it is advisable to emerge glibc and gcc with both patches active, Martin > > otherwise -static compiles will fail again! Sorry, not certain that I understand this... <speculation> I believe that what is happening is that the proPolice handlers have been moved to glibc. So ideally, a system would have a libgcc WITHOUT these symbols defined; they would be defined in glibc. So it may not be easy to bootstrap into such a system from a gentoo system that has gcc with ProPolice: you emerge system, building a new glibc (now with ProPolice patches), then the next time you try to static link you get this error that the symbols are duplicated. So what needs to happen is you need to build a gcc *without* ProPolice patches, now that you have them in glibc. Then try emerge -u system again. </speculation> Is this correct? Or do I mis-understand?
this is the complimentary libgcc removal thing: http://emu.gentoo.org/~pappy/gentoo-x86/sys-devel/gcc/gcc-3.2.3-move-propolice-into-glibc.patch yes, you are right, these both patches have been designed to be utilized together to ensure smooth rolling upgrades. sorry to be causing you trouble so much Alex
to answer your second question, when the glibc emerge and afterwards the gcc emerge are done directly after each other, it works HTH, Alex
*** Bug 34062 has been marked as a duplicate of this bug. ***
20:56:35 <@pappy-> glibc has guard symbols and gcclib has it still because we didnt file the removal logic yet 20:56:45 <@pappy-> so you will fall on your nose with newly emerged glibc 20:56:51 <@pappy-> do this: 20:56:59 <@pappy-> use etdyn stage3 by zhen 20:57:02 <@pappy-> go emerge sync 20:57:08 <@pappy-> then edit the appropr. gcc ebuild please: 20:57:19 <@pappy-> epatch < http://emu.gentoo.org/~pappy/gentoo-x86/sys-devel/gcc/gcc-3.2.3-move-propolice-into-glibc.patch 20:57:29 <@pappy-> but not this line, fetch the patch to /tmp and epatch it in the gcc 20:57:35 <@pappy-> then you can safely continue emerging 20:57:37 <@pappy-> but dont sync around 20:57:47 <@pappy-> caus this will break your gcc ebuild again 20:58:08 <@pappy-> so these are the steps at the moment: 20:58:13 <@pappy-> 1) install etdyn stage3 by zhen 20:58:15 <@pappy-> 2) emerge sync 20:58:17 <@pappy-> 3) emerge glibc 20:58:23 <@pappy-> 4) edit gcc ebuild and emerge gcc 20:58:32 <@pappy-> 5) emerge stable hcc and etc-update and hcc -a 20:58:40 <@pappy-> then you are on the safe side with propolice and hardened-gcc 20:59:06 <@pappy-> and before you sync next time, remember that a further gcc emerge will lead to double problems again: http://bugs.gentoo.org/show_bug.cgi?id=25299 20:59:10 <@pappy-> sorry for making you trouble
23:20:16 <@pappy-> ./glibc-2.3.2-r3.ebuild: # To circumvent problems with propolice __guard and 23:20:16 <@pappy-> ./glibc-2.3.2-r3.ebuild: cd ${S}; epatch ${FILESDIR}/${PV}/${P}-propolice-guard-functions.patch 23:20:16 <@pappy-> ./glibc-2.3.2-r2.ebuild: # To circumvent problems with propolice __guard and 23:20:16 <@pappy-> ./glibc-2.3.2-r2.ebuild: cd ${S}; epatch ${FILESDIR}/${PV}/${P}-propolice-guard-functions-v2.patch 23:20:21 <@pappy-> ./glibc-2.3.2-r9.ebuild: # To circumvent problems with propolice __guard and 23:20:21 <@pappy-> ./glibc-2.3.2-r9.ebuild: cd ${S}; epatch ${FILESDIR}/${PV}/${P}-propolice-guard-functions-v2.patch 23:20:38 <@pappy-> you have to comment out the cd ${S}; epatch ${FILESDIR}/${PV}/${P}-propolice-guard-fu* line for stage1 foo 23:20:46 <@pappy-> this is the only reasonable way of doing it at the moment 23:21:03 <@pappy-> because otherwise you may stop being blinded by the flashbang when gcc builds the first -static binary 23:21:13 <@pappy-> so, do this: 23:21:18 <@pappy-> http://www.gentoo.org/doc/en/gentoo-x86-install.xml 23:21:28 <Primer> that's where I originally started 23:21:37 <@pappy-> after emerge sync 23:21:42 <Primer> that's where I was, basically 23:21:45 <@pappy-> directly go to the glibc portage dir 23:21:51 <@pappy-> and comment out these changes in the ebuilds 23:22:09 <@pappy-> then you go to /usr/portage and run scripts bootstrap.sh 23:22:14 <@pappy-> after you are all set and done 23:22:19 <@pappy-> emerge x86 hardened-gcc 23:22:25 <@pappy-> etc-update to get the hcc.conf right 23:22:26 <@pappy-> hcc -a 23:22:33 <@pappy-> emerge sync to get the glibc back on track 23:22:41 <@pappy-> edit the gcc ebuild by hand to make the removal patch active 23:22:46 <@pappy-> emerge -v glibc gcc 23:22:55 <@pappy-> and be the first real happy propolice gentoo user 23:23:03 <@pappy-> a long road though 23:23:17 <Primer> lovely 23:23:52 <@pappy-> with "after you are all set and done" i mean after you completed the all installation guide and rebooted 23:24:41 <@pappy-> i think the glibc patches have to be marked with if not use bootstrap then add guard patch
18:09:08 <swtaylor> pappy-, seen this before-- /usr/bin/python: relocation error: /usr/bin/python: symbol __guard, version GCC_3.0 not defined in file libgcc_s.so.1 with link time reference to prevent the libgcc function removal patch from removing needed global functions in libgcc.so, we need to run this scanner before actually removing the libgcc functions: 18:22:16 <@pappy-> find / -type f -perm 755 -maxdepth 9 -exec echo "__guard at GCC check in: {}" \; -exec readelf -s {} \; 2>&1 | grep __guard|grep -B1 "\@GCC" this has to be run in the ebuild and put into some more logic like also checking for glibc containing the appropriate functions we are in the middle of a hard path migration which is what i wanted to avoid Azarah, where are you?
added Azarah
when the libgcc gets the functions removed, the following scan must be run prior to applying the move patch: 20:16:10 [/usr/local/chroots/chroot001:24535.pty-s2.epoch] epoch ~ # if [ "$(find / -type f -perm 755 -maxdepth 9 -exec echo "__guard at GCC check in: {}" \; -exec readelf -s {} \; 2>&1 | grep __guard|grep -B1 "\@GCC" 2>&1 1>/dev/null; echo $?)" == "0" ]; then echo "__guard@@GCC references found in dynamically linked binaries"; fi due to swtaylor, this will warn if there are binaries like python2.2 which have still references to guard@@GLIBC i will create a patch out of this all informations and apply it to the bug the bootstrap.sh for stage1 must also be changed to ensure glibc->gcc compilation TIA, Alex
ebuild diff for gcc-3.2.3 at http://dev.gentoo.org/~pappy/gentoo-x86/sys-devel/gcc/gcc-3.2.3-r2.ebuild.diff --- /tmp/gcc-3.2.3-r2.ebuild 2003-11-23 21:10:37.000000000 +0100 +++ gcc-3.2.3-r2.ebuild 2003-11-23 21:37:42.000000000 +0100 @@ -201,6 +201,28 @@ cp ${WORKDIR}/protector.c ${WORKDIR}/${P}/gcc/ || die "protector.c not found" cp ${WORKDIR}/protector.h ${WORKDIR}/${P}/gcc/ || die "protector.h not found" version_patch ${FILESDIR}/3.2.3/gcc-323-propolice-version.patch + + # check for the glibc to have the guard + if [ "$(readelf -s /lib/libc.so.6 | grep GLOBAL | grep OBJECT | grep '__guard')" ] && + [ "$(readelf -s /lib/libc.so.6 | grep GLOBAL | grep FUNC | grep '__stack_smash_handler')" ] + then + ewarn "found sy-libs/glibc with __guard object and __stack_smash_handler function" + ewarn "scanning the system for binaries with __guard - this may take 5-10 minutes" + ewarn "please do not press crtl-C or crtl-Z during this period - it will continue" + if [ "$(find ${ROOT} -type f -perm 755 -maxdepth 9 -exec readelf -s {} \; 2>&1 | grep "__guard\@GCC" 2>&1 1>/dev/null; echo $?)" == "0" ] + then + eerror "found binaries that are dynamically linked to the libgcc with __guard@GCC" + find / -type f -perm 755 -maxdepth 9 -exec echo "__guard at GCC check in: {}" \; -exec readelf -s {} \; 2>&1 | grep __guard|grep -B1 "\@GCC" + eerror "you need to compile these binaries without CFLAGS -fstack-protector and with hcc -r" + eerror "if these binaries continue to be found on this system, the gcc will not be compiled without libgcc guard" + eerror "which will lead to gcc -static -fstack-protector breaking, see http://bugs.gentoo.org/show_bug.cgi?id=25299" + sleep 10 + else + einfo "no binaries with suspicious libgcc __guard@GCC dependencies found, continue to update gcc" + epatch ${FILESDIR}/3.2.3/gcc-3.2.3-move-propolice-into-glibc.patch + fi + fi + # end of check for the glibc to have the guard fi # Patches from Mandrake/Suse ... that is how it looks like when running: http://dev.gentoo.org/~pappy/gentoo-x86/sys-devel/gcc/gcc-3.2.3-r2.ebuild.run.txt >>> Unpacking protector-3.2.2-10.tar.gz to /var/tmp/portage/gcc-3.2.3-r2/work * Working directory: /var/tmp/portage/gcc-3.2.3-r2/work/gcc-3.2.3... * Applying libtool-test.patch... * Applying libtool-tmp.patch... * Applying libtool-sed.patch... * Applying libtool-portage.patch... * Applying gcc-3.2.3-tls-update.patch.bz2... [ ok ] * Applying gcc323-gentoo-branding.patch... [ ok ] * Applying protector.dif... [ ok ] * Applying gcc-323-propolice-version.patch... [ ok ] * found sy-libs/glibc with __guard object and __stack_smash_handler function * scanning the system for binaries with __guard - this may take 5-10 minutes * please do not press crtl-C or crtl-Z during this period - it will continue * no binaries with suspicious libgcc __guard@GCC dependencies found, continue to update gcc * Applying gcc-3.2.3-move-propolice-into-glibc.patch... with a test binary in /tmp: >>> Unpacking protector-3.2.2-10.tar.gz to /var/tmp/portage/gcc-3.2.3-r2/work * Working directory: /var/tmp/portage/gcc-3.2.3-r2/work/gcc-3.2.3... * Applying libtool-test.patch... * Applying libtool-tmp.patch... * Applying libtool-sed.patch... * Applying libtool-portage.patch... * Applying gcc-3.2.3-tls-update.patch.bz2... [ ok ] * Applying gcc323-gentoo-branding.patch... [ ok ] * Applying protector.dif... [ ok ] * Applying gcc-323-propolice-version.patch... [ ok ] * found sy-libs/glibc with __guard object and __stack_smash_handler function * scanning the system for binaries with __guard - this may take 5-10 minutes * please do not press crtl-C or crtl-Z during this period - it will continue * found binaries that are dynamically linked to the libgcc with __guard@GCC __guard at GCC check in: /tmp/python2.2 917: 00000000 32 OBJECT GLOBAL DEFAULT UND __guard@GCC_3.0 (13) 4248: 00000000 32 OBJECT GLOBAL DEFAULT UND __guard@@GCC_3.0 * you need to compile these binaries without CFLAGS -fstack-protector and with hcc -r * if these binaries continue to be found on this system, the gcc will not be compiled without libgcc guard * which will lead to gcc -static -fstack-protector breaking, see http://bugs.gentoo.org/show_bug.cgi?id=25299 * Applying gcc31-loop-load-final-value.patch... [ ok ] * Applying gcc32-strip-dotdot.patch... [ ok ] * Applying gcc32-athlon-alignment.patch... [ ok ] * Applying gcc32-c++-classfn-member-template.patch... [ ok ] * Applying gcc32-mklibgcc-serialize-crtfiles.patch... [ ok ] * Applying gcc32-pr7768.patch... [ ok ] * Applying gcc32-pr8213.patch... [ ok ] * Applying gcc322-ggc_page-speedup.patch... [ ok ] * Fixing Makefiles... Caught signal 2 either hardened-gcc -r or remove -fstack-protector from CFLAGS must be done to not get into problems with gcc -static -fstack-protector when both libgcc and libc contain guard, Alex
check out the UPDATED gcc ebuild patch thanks to solar for pointing out the scanpath logic and speed issues ;-)) http://dev.gentoo.org/~pappy/gentoo-x86/sys-devel/gcc/gcc-3.2.3-r2.ebuild.diff
So from my understanding here is we need to recompile everything in find $(echo $PATH | tr : ' ') -type f -perm -1 -maxdepth 9 -exec echo '__guard at GCC check in: {}' \; -exec readelf -s {} \; 2>&1 | grep __guard | grep -B1 '__guard\@GCC' | grep "__guard at GCC check in:" | cut -d : -f 2- | xargs -n1 qpkg -nc -f | sort | uniq Without -fstack enabled before we should build gcc again. Then after thats complete, we are then supposed to rebuild gcc again and then rebuild all those programs a second time with -fstack enabled?
*** Bug 34183 has been marked as a duplicate of this bug. ***
Maybe this idea is off the wall, but here goes: Is it possible to have two different sets of propolice symbols, one for glibc and one for other places, so that there won't be any name clash. Then the link would have _weak_ references to these symbols. The runtime would try the first set of names. If they are there (non-null), it would use them. Otherwise, it would try the second set. If I understand the problem correctly (not certain I do!), it seems to me that this would be a fix for the propolice/static collision.
*** Bug 32411 has been marked as a duplicate of this bug. ***
a weak reference is no priority or preference thingie it resolves to 0x0 when ld cannot link it in otherwise there must be one (exactly one) function with a name and only that name: __stack_smash_handler and an object, object __guard as a long array size 8 in the namespace of the current program: binary and libraries no matter whether libgcc, crt1.o or glibc provided it HTH, Alex
however, writing an __stack_smash_handler routine that does assembler checks this way: asm(.weak glibc_smash_handle) load mem addr of function glibc_smash_handle into register eax compare eax to zero jmp if not zero call_glibc asm hlt to halt the program when call_glibc cannot work call_glibc: glibc_smash_handle this put into crt1.o or ssp.o in the building process is planned but in a slightly modified idea: the specs file deals with putting ssp.o into the binary when -nostartfiles and/or -nostdlib is issued ssp.o contains only a assembler arch dependent stack_smash_handler issuing a single command: asm(hlt) which will be hacked on arches sparc and ppc also TIA, Alex
*** Bug 34396 has been marked as a duplicate of this bug. ***
*** Bug 34420 has been marked as a duplicate of this bug. ***
What am I doing wrong. The first time I recompiled the packages which claimed to be with __guard without -fstack-protector but with hcc -r, the second time I removed both, but it doesn't change anything. They've still got the __guard symbol and gcc won't merge. Portage 2.0.49-r18 (default-x86-1.4, gcc-3.3.2, glibc-2.3.2-r9, 2.4.20-gentoo-r8) ================================================================= System uname: 2.4.20-gentoo-r8 i686 Pentium III (Katmai) Gentoo Base System version 1.4.3.12 ACCEPT_KEYWORDS="x86 ~x86" AUTOCLEAN="yes" CFLAGS="-O3 -march=pentium3 -fprefetch-loop-arrays -funroll-loops -pipe -fomit-frame-pointer -frerun-loop-opt -falign-functions=4 -fforce-mem -ffast-math -finline-functions -foptimize-sibling-calls -mmmx" CHOST="i686-pc-linux-gnu" COMPILER="gcc3" CONFIG_PROTECT="/etc /usr/kde/2/share/config /usr/kde/3/share/config /usr/share/config /var/qmail/control" CONFIG_PROTECT_MASK="/etc/gconf /etc/env.d" CXXFLAGS="-O3 -march=pentium3 -fprefetch-loop-arrays -funroll-loops -pipe -fomit-frame-pointer -frerun-loop-opt -falign-functions=4 -fforce-mem -ffast-math -finline-functions -foptimize-sibling-calls -mmmx -Wno-deprecated" DISTDIR="/usr/portage/distfiles" FEATURES="autoaddcvs ccache sandbox" GENTOO_MIRRORS="http://mirrors.sec.informatik.tu-darmstadt.de/gentoo http://212.219.247.14/sites/www.ibiblio.org/gentoo/ http://212.219.247.15/sites/www.ibiblio.org/gentoo/" MAKEOPTS="-j2" PKGDIR="/usr/portage/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="" SYNC="rsync://rsync.de.gentoo.org/gentoo-portage" USE="acl apache2 berkdb crypt gd gdbm gif imap imlib innodb ipv6 jpeg libwww maildir mbox memlimit motif mysql ncurses nls oss pam pdflib perl png python readline ruby ruby18 slang sse ssl tcpd x86 xml2 xmms zlib"
maybe you should reduce or remove CFLAGS temporarily to compile glibc thanks, Alex
In #38 there isn't stated that I have to recompile glibc. So I need to remove -fstack-protector, recompile all programs with the __guard symbol, then recompile gcc, then recompile glibc & the programs with -fstack-protector?
remember to disable ccache if you have mysterious problems with reemerging the apps and still remaining the guard! thanks to Strider echo eerror "also you have to make sure that using ccache needs the cache to be flushed" eerror "wipe out /var/tmp/ccache or /root/.ccache, this will remove possible saved" eerror "-fstack-protector arguments that still may reside in such a compiler cache" echo
*** Bug 34619 has been marked as a duplicate of this bug. ***
*** Bug 34591 has been marked as a duplicate of this bug. ***
*** Bug 34537 has been marked as a duplicate of this bug. ***
*** Bug 34622 has been marked as a duplicate of this bug. ***
Here's a command to do a scan for packages which need to be rebuilt that I believe is faster than the one in gcc-3.3.2-r3.ebuild and certainly gives easier to read output. Note that while the pipeline is longer, there's generally not much data flowing through it, and qpkg is not called for each executable found. Command and sample output follow: # find / -type f -perm -1 -maxdepth 9 -exec echo -n '__guard at GCC check in: {} ' \; -exec readelf -s {} \; 2>&1 | grep __guard | grep -B1 '__guard\@GCC' | egrep '^__guard' | sed -e 's/^__guard.*: //' | xargs -n1 qpkg -f -v -nc | sort -u dev-db/mysql-4.0.14-r2 dev-lang/python-2.2.3-r5 media-gfx/imagemagick-5.5.6-r1 sys-devel/gcc-3.2.3-r2 #
*** Bug 34125 has been marked as a duplicate of this bug. ***
also an issue during bootstrap from stage1 with 2004.0 stages.
*** Bug 38036 has been marked as a duplicate of this bug. ***
The current version of propolice should fix this. This is in portage as gcc-3.3.2-r{4,5} I think. Please test and report back so we can close this bug.
Ok well I've tested it plently and it works perfect with the current stable gcc.
how the HELL am I supposed to recompile GCC if I can't recompile when GCC finds GCC has __guard in it? I'd love to recompile GCC using GCC to remove that guard but just that won't GCC do? Someone needs to be shot. repeatedly.
Is this rogue __guard symbol in libstdc++? If so, could you check to see if you have a rogue libstdc++.so* hiding in /lib/usr/lib/*? I ran into this kind of oddity at one point, some how a copy of an older gcc-lib got stuck in /lib/usr, and this hosed the __guard checker, blocking me from upgrading until I removed the bad copy.
the following are the only elf files that contain __guard. they all belong to the gcc installation currently installed /usr/i686-pc-linux-gnu/gcc-bin/3.2/gij /usr/lib/gcc-lib/i686-pc-linux-gnu/3.2.3/libgcj.so.3.0.0 /usr/lib/gcc-lib/i686-pc-linux-gnu/3.2.3/libstdc++.so.5.0.3 Removed them. now emerge doesn't work anymore, duh. (can get them back for I am using buildpkg directive, so I'll have a *.tar.bz2 somewhere - but it will still contain the __guard directive which keeps me from building gcc without it. I hate computers =P The only solution I see is to merge the live CD's GCC tarball and use that GCC to update to a more recent version
Well, I actually prebuilt a gcc package with the proper flags on a different system and copied over, untarred it. works out. but geez... emerge gcc really SHOULD work if the only program on the system that still has the broken __guard flags in it is the old gcc, or not?
It's not gcc itself persay, but the awk scanner tool which looks for the __guard symbols. In theory, you could've commented out the part of the ebuild which runs the scanner, merged gcc with -fno-stack-protector, and then merged gcc again with -fstack-protector (using a newer gcc, like 3.3.x), and that would have eliminated the __guard errors. These stem from an older propolice that was included in previous gcc ebuilds.
I've got sneaky voodoo magic to work around this incase anybody is totally stuck. What I've done is rename the __guard@GCC symbol to something else in the ELF, and get on with the show.
Please help me, I'm stuck after hardened bootstrap process, emerge modutils fails. 2004Q0. What should I do to make it work? Gentoo Base System version 1.4.10 Portage 2.0.50-r6 (hardened-x86-2004.0, gcc-3.3.2, glibc-2.3.2-r9, 2.6.1-gentoo-r2) ================================================================= System uname: 2.6.1-gentoo-r2 i686 Intel(R) Celeron(R) CPU 2.40GHz Autoconf: Automake: ACCEPT_KEYWORDS="x86" AUTOCLEAN="yes" CFLAGS="-march=pentium3 -mcpu=pentium3 -mfpmath=sse -mmmx -msse -O3 -pipe -fstack-protector" CHOST="i686-pc-linux-gnu" COMPILER="gcc3" CONFIG_PROTECT="/etc /usr/kde/2/share/config /usr/kde/3/share/config /usr/share/config /var/qmail/control" CONFIG_PROTECT_MASK="/etc/gconf /etc/terminfo /etc/env.d" CXXFLAGS="-march=pentium3 -mcpu=pentium3 -mfpmath=sse -mmmx -msse -O3 -pipe" DISTDIR="/usr/portage/distfiles" FEATURES="autoaddcvs ccache sandbox sfperms strict" GENTOO_MIRRORS="ftp://ftp.rxd.hu http://gentoo.math.bme.hu http://linux.rz.ruhr-uni-bochum.de/download/gentoo-mirror/ ftp://ftp.uni-erlangen.de/pub/mirrors/gentoo http ://ftp.snt.utwente.nl/pub/os/linux/gentoo http://mirror.datapipe.net/gentoo" MAKEOPTS="-j2" PKGDIR="/usr/portage/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="" SYNC="rsync://rsync.gentoo.org/gentoo-portage" USE="acl berkdb caps crypt imap mmap mmx nls pam pic pnp readline slang sse ssl tcpd unicode x86 zlib"
