These files get linked into every executable built by the system which means that every compiled executable will be mismarked. ppc64 works quite well when non-executable markings are placed on ELF files. root@G5 0 glibc # qlist -o glibc | scanelf -qeBf - !WX --- --- /usr/lib64/libmcheck.a !WX --- --- /usr/lib64/libieee.a !WX --- --- /usr/lib64/Scrt1.o !WX --- --- /usr/lib64/Mcrt1.o !WX --- --- /usr/lib64/crti.o !WX --- --- /usr/lib64/crtn.o !WX --- --- /usr/lib64/crt1.o !WX --- --- /usr/lib64/libc_stubs.a !WX --- --- /usr/lib64/gcrt1.o [ebuild R ] sys-libs/glibc-2.3.6-r3 -build -erandom -glibc-compat20 -glibc-omitfp -hardened -linuxthreads-tls (-multilib) +nls +nptl +nptlonly -pic -profile (-selinux) -userlocales 0 kB Portage 2.0.54 (default-linux/ppc/2005.1/ppc64/64bit-userland, gcc-3.4.5, glibc-2.3.6-r3, 2.6.15-gentoo-r1 ppc) ================================================================= System uname: 2.6.15-gentoo-r1 ppc PPC970, altivec supported Gentoo Base System version 1.6.14 dev-lang/python: 2.4.2 sys-apps/sandbox: 1.2.12 sys-devel/autoconf: 2.13, 2.59-r6 sys-devel/automake: 1.4_p6, 1.5, 1.6.3, 1.7.9-r1, 1.8.5-r3, 1.9.6-r1 sys-devel/binutils: 2.16.1-r1 sys-devel/libtool: 1.5.22 virtual/os-headers: 2.6.11-r2 ACCEPT_KEYWORDS="ppc64 ~ppc64" AUTOCLEAN="yes" CBUILD="powerpc64-unknown-linux-gnu" CFLAGS="-O2 -pipe" CHOST="powerpc64-unknown-linux-gnu" CONFIG_PROTECT="/etc /usr/kde/2/share/config /usr/kde/3/share/config /usr/share/X11/xkb /usr/share/config /var/qmail/control" CONFIG_PROTECT_MASK="/etc/gconf /etc/terminfo /etc/env.d" CXXFLAGS="-O2 -pipe" DISTDIR="/usr/portage/distfiles" FEATURES="autoconfig buildpkg ccache distlocks noauto noinfo sandbox sfperms splitdebug" GENTOO_MIRRORS="http://distfiles.gentoo.org http://distro.ibiblio.org/pub/linux/distributions/gentoo" LDFLAGS="-Wl,-O1 -Wl,-z,relro" MAKEOPTS="-j6" PKGDIR="/var/tmp/binpkgs" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="/usr/portage/local" SYNC="rsync://rsync.gentoo.org/gentoo-portage" USE="ppc64 X a52 aac aalib acl altivec audiofile berkdb bitmap-fonts boundschecking bzip2 cairo cddb cdr crypt css dts dvdr encode expat fame ffmpeg flac gif glitz gpm ibm imagemagick ipv6 jbig jpeg jpeg2k libcaca lzo mad mikmod mjpeg multislot musepack ncurses nls nptl nptlonly ogg perl png python quicktime readline rle samba sdl sndfile spell ssl tcltk tcpd theroa tiff truetype truetype-fonts type1-fonts udev unicode vcd vorbis xinetd xml xmms xprint xrandr xvid yv12 zlib userland_GNU kernel_linux elibc_glibc" Unset: ASFLAGS, CTARGET, LANG, LC_ALL, LINGUAS
ping.. Fixing this bug allows you to take advantage of the PPC64 CPU correctly.
I realy just don't have the knowledge to fix this. any documents you can point me to?
(In reply to comment #2) > I realy just don't have the knowledge to fix this. any documents you can point > me to? The docs are hosted under the hardened pages but it's not really a hardened feature. http://hardened.gentoo.org/gnu-stack.xml#doc_chap6 The crt* objects are built from asm crt*.S files which probably just lack the 2-3 lines needed.
Hmm if this is what I think it is I think sjmunroe / ryanarn cleaned this up in later versions of glibc, have you guys looked at 2.5?
looks broken to me still: root@G5[ppc64] 0 / # /lib/libc.so.6 | head -n1 GNU C Library stable release version 2.5, by Roland McGrath et al. root@G5[ppc64] 0 / # scanelf -qe /usr/lib64/*.o !WX --- --- /usr/lib64/Mcrt1.o !WX --- --- /usr/lib64/Scrt1.o !WX --- --- /usr/lib64/crt1.o !WX --- --- /usr/lib64/crti.o !WX --- --- /usr/lib64/crtn.o !WX --- --- /usr/lib64/gcrt1.o
Hmm I half wonder if scanelf doesn't have some sort of bug. sjmunroe sees from /proc/pid/map <sjmunroe> fffffe73000-fffffe88000 rw-p fffffe73000 00:00 0 [stack] and when he runs scanelf on the same system: <sjmunroe> it is the !WX ----- stuff clearly something doesn't quite add up there. still for gentoo I'm getting : <tgall_foo> ffffff81000-ffffff96000 rwxp ffffff81000 00:00 0 [stack] where obviously the exec bit IS on and it shouldn't be for a user space stack. sjmunroe is telling me that the 2.6.5+ kernels had noexec in kernel but I'm not seeing a kernel config for that and obviously the above would seem to indicate that perhaps something isn't config'd on that should be. Still that might be just for kernel space stacks. Anyway I'm not against to picking this up. I'll take action soon as I have a spare scratch monkey and a few moments.
Hmm I half wonder if scanelf doesn't have some sort of bug. sjmunroe sees from /proc/pid/map <sjmunroe> fffffe73000-fffffe88000 rw-p fffffe73000 00:00 0 [stack] and when he runs scanelf on the same system: <sjmunroe> it is the !WX ----- stuff clearly something doesn't quite add up there. still for gentoo I'm getting : <tgall_foo> ffffff81000-ffffff96000 rwxp ffffff81000 00:00 0 [stack] where obviously the exec bit IS on and it shouldn't be for a user space stack. sjmunroe is telling me that the 2.6.5+ kernels had noexec in kernel but I'm not seeing a kernel config for that and obviously the above would seem to indicate that perhaps something isn't config'd on that should be. Still the following http://lkml.org/lkml/2005/3/17/24 confirms at least the kernel defaults and as you correctly point out the lack of stack markings. The part I'm somewhat quizzical on is shouldn't that be in upstream glibc? If it's not (and I haven't check) seems like we ought to be pester them to. Anyway I'm not against to picking this up. I'll take action soon as I have a spare scratch monkey and a few moments.
The !WX marking in scanelf means that the ELF file lacks a PT_GNU_STACk marking.
scanelf doesnt lie ... '!WX' in the first field means the object is missing ELF gnu stack markings if you dont believe scanelf, run `readelf` yourself relocatable files (*.o) should have a .note.GNU-stack section header while executable/shared files (.so/etc...) should have a GNU_STACK program header my ppc64 shows the crt*.o objects missing .note.GNU-stack sections which means the toolchain probably fails to add it automatically ... and indeed, gcc-4.1.1 and older fail to do this on ppc64: $ echo "" | gcc -S -x c - -o - | grep GNU-stack [ppc64 -> nothing] [amd64 -> .note.GNU-stack section]
Yup I'm well past that. I had a long day discussing things with various maintainers yesterday. At the end of the day I was getting lots of, gee that should "just work" .. implying that it is the impression of kernel, glibc and binutils that across the board given the level of code we're talking about here it should "just work" and obviously that isn't the case. I need to talk to one guru, Alan Modra as of yet. This will get done. Yes I could just take your patch and go for gentoo, but if the powers that be believe that this ought to just work then I think we owe upstream a little investigation time.
Seems gcc deliberately does not add the GNU-stack marking for 64-bit PPC ELF files. From (gcc-4.1.1-r3) gcc/config/rs6000/rs6000.c: 18122 static void 18123 rs6000_elf_end_indicate_exec_stack (void) 18124 { 18125 if (TARGET_32BIT) 18126 file_end_indicate_exec_stack (); 18127 } file_end_indicate_exec_stack () is the function that adds the .note.GNU-stack section - gcc/varasm.c: 5735 void 5736 file_end_indicate_exec_stack (void) 5737 { 5738 unsigned int flags = SECTION_DEBUG; 5739 if (trampolines_created) 5740 flags |= SECTION_CODE; 5741 5742 named_section_flags (".note.GNU-stack", flags); 5743 } I guess we should ask the gcc guys why.
ok; some more details: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21098 powerpc64 doesn't use file_end_indicate_exec_stack() because ppc64 doesn't use trampolines (the only source of executable stack from the C compiler) to implement nested functions. It should still be generating the .note.GNU-stack section, from gcc/config/rs6000/ppc-asm.h so something is up there. http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21098#c7
Created attachment 105639 [details, diff] Add .note.GNU-stack to asm objects where it was missing, and generate .note.GNU-stack for 64-bit objects (always indicating no exec stack) This does the trick. An alternative would be to modify the linker so that it defaults to read-only stack on 64-bit ppc; however I think adding the .note.GNU-stack section is more consistent.
no ... modifying the linker breaks backwards compatibility which is why the behavior has always been no gnu stack section -> set all perms
(btw - rebuild glibc after having gcc with this patch, to get crt1.o etc marked properly)
So on ppc64/2007.0. Unless we force noexecstack and rebuild glibc and -e world etc. Everything gets mismarked on vanilla systems and they end up having ld.so change memory segments as rwxp.
i'm pretty sure binutils-2.18 + glibc-2.6.1 + gcc-4.1.2 has this all set on my ppc64 system at least: root@G5[ppc64] 0 ~ # scanelf -a /bin/bash TYPE PAX PERM ENDIAN STK/REL/PTL TEXTREL RPATH BIND FILE ET_EXEC --Mxe- 0755 BE RW- R-- RW- - - LAZY /bin/bash
