cp (part of coreutils) compiled with a hardened toolchain on ppc gets killed when used with '-r' or '-R' Reproducible: Always Steps to Reproduce: Case 1: 1. configure gcc to use the hardened specs 2. USE="hardened pic pie" emerge coreutils 3. cp -r dir1 dir2 or Case 2: 1. configure gcc to use the hardened specs 2. add maketest to FEATURES in make.conf 3. USE="hardened pic pie" emerge coreutils Actual Results: Result case 1: cp: stack smashing attack in function copy_internal() Aborted Result case 2: emerge of coreutils fails, because maketest is not passed. Expected Results: cp copies recursively when asked to do so without causing itself to be killed for trying to smash the stack Portage 2.0.51.19 (hardened/ppc, gcc-3.4.3, glibc-2.3.4.20041102-r1, 2.6.11-gentoo-r3-nixed ppc) ================================================================= System uname: 2.6.11-gentoo-r3-nixed ppc 7447A, altivec supported Gentoo Base System version 1.4.16 Python: dev-lang/python-2.3.4-r1 [2.3.4 (#1, Mar 25 2005, 18:29:53)] dev-lang/python: 2.3.4-r1 sys-devel/autoconf: 2.13, 2.59-r6 sys-devel/automake: 1.5, 1.8.5-r3, 1.7.9-r1, 1.9.4, 1.6.3, 1.4_p6 sys-devel/binutils: 2.15.90.0.3-r3 sys-devel/libtool: 1.5.10-r4 virtual/os-headers: 2.6.8.1 ACCEPT_KEYWORDS="ppc" AUTOCLEAN="yes" CFLAGS="-O2 -mtune=G4 -maltivec -mabi=altivec -fno-strict-aliasing -pipe" CHOST="powerpc-unknown-linux-gnu" CONFIG_PROTECT="/etc /usr/kde/2/share/config /usr/kde/3/share/config /usr/lib/X11/xkb /usr/share/config /var/qmail/control" CONFIG_PROTECT_MASK="/etc/gconf /etc/terminfo /etc/env.d" CXXFLAGS="-O2 -mtune=G4 -maltivec -mabi=altivec -fno-strict-aliasing -pipe" DISTDIR="/usr/portage/distfiles" FEATURES="autoaddcvs autoconfig ccache distlocks maketest sandbox test userpriv usersandbox" GENTOO_MIRRORS="http://distfiles.gentoo.org http://distro.ibiblio.org/pub/Linux/distributions/gentoo" MAKEOPTS="-j2" PKGDIR="/usr/portage//packages/ppc/" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage/" PORTDIR_OVERLAY="/usr/local/portage" SYNC="rsync://rsync.gentoo.org/gentoo-portage" USE="X alsa altivec berkdb cdr crypt cups divx4linux dlloader dvd dvdread esd gdbm gif gtk hardened imagemagick imlib java jpeg ldap motif mpeg ncurses network nls oggvorbis opengl pam perl pic pie png ppc python readline real ssl tcpd theora tiff truetype xml2 xmms xv xvid zlib" Unset: ASFLAGS, CBUILD, CTARGET, LANG, LC_ALL, LDFLAGS
Created attachment 54588 [details] output of failed maketest for coreutils
It is very common for maketest to fail, it should not be enabled system wide. I'm not sure its that useful at all, really. Let's stick to case #1
same problem in "ps" if try to look processes in small X terminal :-)
From: Lukasz Stelmach <stelmacl@ee.pw.edu.pl> To: hardened@gentoo.org Subject: bug 86857 Date: Tue, 7 Jun 2005 20:56:10 +0200 (14:56 EDT) Greetings. I would like to confirm the bug in subj. It is really anoying to have such a bug when I try to install Gentoo on a not so new iMac G3. You could at least say somewhere in the Handbook that "hardened" doesn't work on PPC and I wouldn't even think about it. Blaah... Bye. -- Up till starting soon the hardened team has had no direct access to ppc hardware. Thanks to a loaner of from the OSL our team will have access to such hardware and er will be able test, confirm and fix bugs where we see them on the ppc32 arch related to hardened things. For now you brave soles are more or less the testing people. See the roadmap http://www.gentoo.org/proj/en/hardened/roadmap.xml#doc_chap4 The general flow of things works like this. We ask a few users or other devs to test that all the cflags that a hardened compiler would enable by default work for a given arch. If all flags work then we add a hardened/$ARCH profile by the request of testers. When we proper access to or own dedicated hardware *and* we produce stage[1-3] that get mirrored during release cycle then we are officially supporting the profile for the given arch. So.. In general we are not going to just keep commenting on bugs and updating our documentation (which already states that ppc is in testing only) to say that there has been no progress on a arch porting bug unless there has been. As for working around the bug that should be pretty obvious. gcc-config -l and gcc-config number and switch to non hardened specs for the given package that fails. Leaving these types of bugs in an open state also serves everybody good as it allows the users and future hardened ppc porters a chance see that a bug might exist and if/when somebody does have a ppc they can look into and find a fix just like the rest of us.
We got the ppc and are able to test now. The cp failure is caused by when -fno-strict-aliasing is enabled with -pie. This shows with coreutils and sed atleast.
Created attachment 61089 [details, diff] sed-4.1.4-strict-aliasing.patch Try this
Created attachment 61090 [details, diff] coreutils-5.2.1-r6-strict-aliasing.patch And this one for coreutils
*** Bug 95821 has been marked as a duplicate of this bug. ***
That kind of workaround may/will lead to ill compiled executables if in the source there are type punning expressions. Please do not use it. some programs known for that issue: diffutils openssl.
If -fno-strict-aliasing is needed for these packages to build properly, surely it would be set by the build? Since the default flags for the ppc profiles don't include -fno-strict-aliasing, filtering it from user settings should be as safe as the profile.
(In reply to comment #9) > That kind of workaround may/will lead to ill compiled executables if in the > source there are type punning expressions. Please do not use it. > some programs known for that issue: diffutils openssl. Could you elaborate that? I'm curious why this is a problem for ppc, but not for other architectures. Produces gcc broken optimization code on ppc?
<gengor> nixnut: ping <nixnut> gengor: pong <gengor> !bug 86857 <Willikins> gengor: https://bugs.gentoo.org/86857 "USE=hardened `cp -{r,R}` on ppc killed by ssp"; Gentoo Linux, Hardened; NEW; nixnut@g.o:hardened@g.o <gengor> nixnut: ^^ still apply to any of the coreutils in the tree? <nixnut> gengor: don't think so. Haven't seen it for ages <gengor> nixnut: mind closing it out? Closing as FIXED. Re-open if still an issue.
