Something must be wrong with this code... or perhaps gcc? Don't know if that's related, but I've recently upgraded gcc from 3.4.6 to 4.3.4. Whole 'emerge -eav system/world' went just fine! Just this one package fails (I had to use --skipfirst to finish the system update). It fails always in the same place: on UAccept.c file (with MAKEOPTS="-j3" there are some concurrent ERRORs, but this one is consistent). Always with the same message: "x86_64-pc-linux-gnu-gcc: Internal error: Segmentation fault (program cc1)" Disabling CHOST or this MAKEOPTS doesn't help. Rebooting the system doesn't help. Can't check if the previous ncftp version would still work, because it's no longer in the portage tree. Now I've also noticed - when that segfault happens, this is what goes into syslog: kernel: grsec: ... signal 11 sent to /usr/libexec/gcc/x86_64-pc-linux-gnu/4.3.4/cc1[cc1:26009] uid/euid:0/0 gid/egid:0/0, parent /usr/x86_64-pc-linux-gnu/gcc-bin/4.3.4/x86_64-pc-linux-gnu-gcc[x86_64-pc-linux:26008] uid/euid:0/0 gid/egid:0/0 kernel: cc1[26009]: segfault at 38fc42d54550 ip 00000000008aacc4 sp 00007540443f36e8 error 4 in cc1[400000+69d000] kernel: grsec: ... signal 11 sent to /usr/libexec/gcc/x86_64-pc-linux-gnu/4.3.4/cc1[cc1:26009] uid/euid:0/0 gid/egid:0/0, parent /usr/x86_64-pc-linux-gnu/gcc-bin/4.3.4/x86_64-pc-linux-gnu-gcc[x86_64-pc-linux:26008] uid/euid:0/0 gid/egid:0/0 kernel: grsec: ... denied resource overstep by requesting 4096 for RLIMIT_CORE against limit 0 for /usr/libexec/gcc/x86_64-pc-linux-gnu/4.3.4/cc1[cc1:26009] uid/euid:0/0 gid/egid:0/0, parent /usr/x86_64-pc-linux-gnu/gcc-bin/4.3.4/x86_64-pc-linux-gnu-gcc[x86_64-pc-linux:26008] uid/euid:0/0 gid/egid:0/0 Reproducible: Always Steps to Reproduce: emerge ncftp Actual Results: Failed to emerge net-ftp/ncftp-3.2.3 Expected Results: successful emerge Portage 2.1.6.13 (default/linux/amd64/10.0, gcc-4.3.4, glibc-2.10.1-r1, 2.6.28-hardened-r9 x86_64) ================================================================= System uname: Linux-2.6.28-hardened-r9-x86_64-Intel-R-_Core-TM-2_Duo_CPU_E8400_@_3.00GHz-with-gentoo-1.12.13 Timestamp of tree: Sun, 17 Jan 2010 16:00:01 +0000 app-shells/bash: 4.0_p35 dev-lang/python: 2.6.4 sys-apps/baselayout: 1.12.13 sys-apps/sandbox: 1.6-r2 sys-devel/autoconf: 2.63-r1 sys-devel/automake: 1.9.6-r2, 1.10.2 sys-devel/binutils: 2.18-r3 sys-devel/gcc-config: 1.4.1 sys-devel/libtool: 2.2.6b virtual/os-headers: 2.6.27-r2 ACCEPT_KEYWORDS="amd64" CBUILD="x86_64-pc-linux-gnu" CFLAGS="-O2 -pipe" CHOST="x86_64-pc-linux-gnu" CONFIG_PROTECT="/etc" CONFIG_PROTECT_MASK="/etc/ca-certificates.conf /etc/env.d /etc/fonts/fonts.conf /etc/gconf /etc/php/apache2-php5/ext-active/ /etc/php/cgi-php5/ext-active/ /etc/php/cli-php5/ext-active/ /etc/revdep-rebuild /etc/sandbox.d /etc/terminfo /etc/udev/rules.d" CXXFLAGS="-O2 -pipe" DISTDIR="/usr/portage/distfiles" FEATURES="distlocks fixpackages parallel-fetch protect-owned sandbox sfperms strict unmerge-orphans userfetch" GENTOO_MIRRORS="http://mirror.ovh.net/gentoo-distfiles/ http://gentoo.osuosl.org/" LANG="pl_PL.utf8" LDFLAGS="-Wl,-O1" LINGUAS="pl en" PKGDIR="/usr/portage/packages" PORTAGE_CONFIGROOT="/" PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --compress --force --whole-file --delete --stats --timeout=180 --exclude=/distfiles --exclude=/local --exclude=/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="/usr/local/portage" SYNC="rsync://rsync.gentoo.org/gentoo-portage" USE="X acl amd64 berkdb bzip2 cli cracklib crypt cups cxx dri fortran gdbm gpm iconv mmx modules mudflap multilib ncurses nls nptl nptlonly openmp pam pcre perl pppd python readline reflection session spl sse sse2 ssl sysfs tcpd unicode xorg zlib" ALSA_CARDS="ali5451 als4000 atiixp atiixp-modem bt87x ca0106 cmipci emu10k1x ens1370 ens1371 es1938 es1968 fm801 hda-intel intel8x0 intel8x0m maestro3 trident usb-audio via82xx via82xx-modem ymfpci" ALSA_PCM_PLUGINS="adpcm alaw asym copy dmix dshare dsnoop empty extplug file hooks iec958 ioplug ladspa lfloat linear meter mmap_emul mulaw multi null plug rate route share shm softvol" APACHE2_MODULES="actions alias auth_basic authn_alias authn_anon authn_dbm authn_default authn_file authz_dbm authz_default authz_groupfile authz_host authz_owner authz_user autoindex cache dav dav_fs dav_lock deflate dir disk_cache env expires ext_filter file_cache filter headers include info log_config logio mem_cache mime mime_magic negotiation rewrite setenvif speling status unique_id userdir usertrack vhost_alias" ELIBC="glibc" INPUT_DEVICES="keyboard mouse evdev" KERNEL="linux" LCD_DEVICES="bayrad cfontz cfontz633 glk hd44780 lb216 lcdm001 mtxorb ncurses text" LINGUAS="pl en" RUBY_TARGETS="ruby18" USERLAND="GNU" VIDEO_CARDS="fbdev glint intel mach64 mga neomagic nv r128 radeon savage sis tdfx trident vesa via vmware voodoo" Unset: CPPFLAGS, CTARGET, EMERGE_DEFAULT_OPTS, FFLAGS, INSTALL_MASK, LC_ALL, MAKEOPTS, PORTAGE_COMPRESS, PORTAGE_COMPRESS_FLAGS, PORTAGE_RSYNC_EXTRA_OPTS
Created attachment 216753 [details] build.log
Created attachment 216754 [details] environment
That seems to be a problem with your toolchain. You could try re-emerging gcc, but I doubt that'll have any effect ...
I guess it's the combination of a kernel with grsec and userland without grsec.
(In reply to comment #4) > ... a kernel with grsec and userland without grsec. Can you elaborate that - "userland without grsec"? Do you mean I should emerge all packages with "hardened" flag? Or perhaps some specific ones? I didn't do whole system hardened, because that caused too many problems with for example VirtualBox. Just the kernel. I assumed that's already a big enough security benefit. As for Patrick's advise: > You could try re-emerging gcc ... I believe I did just gcc and glibc, then '-e system', THEN '-e world'. So it's been re-emerged plenty of times. Should I do it again?
coventry ~ # emerge --info Portage 2.1.8.3 (default/linux/x86/10.0, gcc-4.4.3, glibc-2.11.1-r0, 2.6.29-hardened i686) ================================================================= System uname: Linux-2.6.29-hardened-i686-Intel-R-_Xeon-TM-_CPU_2.66GHz-with-gentoo-2.0.1 Timestamp of tree: Thu, 20 May 2010 23:15:02 +0000 app-shells/bash: 4.1_p7 dev-lang/python: 2.6.5-r2, 3.1.2-r3 dev-util/cmake: 2.8.1-r1 sys-apps/baselayout: 2.0.1 sys-apps/openrc: 0.6.1-r1 sys-apps/sandbox: 2.2 sys-devel/autoconf: 2.65 sys-devel/automake: 1.10.3, 1.11.1 sys-devel/binutils: 2.20.1-r1 sys-devel/gcc: 4.4.3-r2 sys-devel/gcc-config: 1.4.1 sys-devel/libtool: 2.2.6b virtual/os-headers: 2.6.33 ACCEPT_KEYWORDS="x86 ~x86" ACCEPT_LICENSE="* -@EULA" CBUILD="i686-pc-linux-gnu" CFLAGS="-march=native -O2 -pipe -fomit-frame-pointer" CHOST="i686-pc-linux-gnu" CONFIG_PROTECT="/etc" CONFIG_PROTECT_MASK="/etc/ca-certificates.conf /etc/env.d /etc/gconf /etc/gentoo-release /etc/revdep-rebuild /etc/sandbox.d /etc/terminfo" CXXFLAGS="-march=native -O2 -pipe -fomit-frame-pointer" DISTDIR="/usr/portage/distfiles" FEATURES="assume-digests distlocks fixpackages news parallel-fetch parallelfetch protect-owned sandbox sfperms strict unmerge-logs unmerge-orphans userfetch" GENTOO_MIRRORS="http://ftp.snt.utwente.nl/pub/os/linux/gentoo" LANG="en_US" LC_ALL="C" LDFLAGS="-Wl,-O1" MAKEOPTS="-j4" PKGDIR="/usr/portage/packages" PORTAGE_CONFIGROOT="/" PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --compress --force --whole-file --delete --stats --timeout=180 --exclude=/distfiles --exclude=/local --exclude=/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" SYNC="rsync://rsync.nl.gentoo.org/gentoo-portage" USE="caps gnutls hardened ncurses nptl nptlonly pam perl pic python quotas readline ssl symlink tcpd threads unicode x86 xml" ALSA_CARDS="ali5451 als4000 atiixp atiixp-modem bt87x ca0106 cmipci emu10k1 emu10k1x ens1370 ens1371 es1938 es1968 fm801 hda-intel intel8x0 intel8x0m maestro3 trident usb-audio via82xx via82xx-modem ymfpci" ALSA_PCM_PLUGINS="adpcm alaw asym copy dmix dshare dsnoop empty extplug file hooks iec958 ioplug ladspa lfloat linear meter mmap_emul mulaw multi null plug rate route share shm softvol" APACHE2_MODULES="actions alias auth_basic authn_alias authn_anon authn_dbm authn_default authn_file authz_dbm authz_default authz_groupfile authz_host authz_owner authz_user autoindex cache dav dav_fs dav_lock deflate dir disk_cache env expires ext_filter file_cache filter headers include info log_config logio mem_cache mime mime_magic negotiation rewrite setenvif speling status unique_id userdir usertrack vhost_alias" ELIBC="glibc" INPUT_DEVICES="keyboard mouse evdev" KERNEL="linux" LCD_DEVICES="bayrad cfontz cfontz633 glk hd44780 lb216 lcdm001 mtxorb ncurses text" RUBY_TARGETS="ruby18" USERLAND="GNU" VIDEO_CARDS="fbdev glint intel mach64 mga neomagic nv r128 radeon savage sis tdfx trident vesa via vmware voodoo" XTABLES_ADDONS="quota2 psd pknock lscan length2 ipv4options ipset ipp2p iface geoip fuzzy condition tee tarpit sysrq steal rawnat logmark ipmark dhcpmac delude chaos account" Unset: CPPFLAGS, CTARGET, EMERGE_DEFAULT_OPTS, FFLAGS, INSTALL_MASK, LINGUAS, PORTAGE_COMPRESS, PORTAGE_COMPRESS_FLAGS, PORTAGE_RSYNC_EXTRA_OPTS, PORTDIR_OVERLAY I'm running a hardened kernel as well and the rest of my userland is not hardened. Can we get this fixed please? This bug also applies to the current ncftp-3.2.4 ebuild in portage.
Addendum: sorry I meant to say that I *DO* have hardened in my USE flags (doh).
I'm also running into this because I'm making binpackages in a non-hardened chroot on a hardened server. Am I not supposed to do that? Anyone resolved this by tweaking RLIMITs maybe?
OK, it seems I fixed this by disabling RANDMMAP on the cc1 executable: # paxctl -r usr/libexec/gcc/i686-pc-linux-gnu/4.4.3/cc1 # paxctl -v usr/libexec/gcc/i686-pc-linux-gnu/4.4.3/cc1 PaX control v0.5 Copyright 2004,2005,2006,2007 PaX Team <pageexec@freemail.hu> - PaX flags: -------x-e-r [cc1] RANDEXEC is disabled EMUTRAMP is disabled RANDMMAP is disabled Now the question is: Is it a bug if cc1 segfaults? Strangely enough, only ncftp triggers this. Then who should I talk to about it? GCC or ncftp people?
This bug is still present in the current ncftp-3.2.4.1 ebuild in portage. What more info is needed?
Can somebody please reopen this thing? It's far from resolved and I got news. I talked to Mike Gleason about this, and he pointed me to the fact that the ebuild script is what triggers the segfault. That is, when you just compile the thing manually by ./configure; make; right from the archive, the segfault is never triggered. Mike also pointed out that if gcc segfaults, it's most definitely a gcc bug. So I guess we should file a gcc bug for this...
Here, it's reopened. I haven't been using ntftp since this bug prevented me from installing it (don't really need it this much), but I've just checked - it still segfaults with 3.2.4 on my system.
(In reply to comment #11) > Can somebody please reopen this thing? It's far from resolved and I got news. I > talked to Mike Gleason about this, and he pointed me to the fact that the > ebuild script is what triggers the segfault. That is, when you just compile the > thing manually by ./configure; make; right from the archive, the segfault is > never triggered. Er, is that what he said would happen or did you actually test this? We could have a sandbox problem here - I don't see anything else between the kernel and the shell. > Mike also pointed out that if gcc segfaults, it's most definitely a gcc bug. So > I guess we should file a gcc bug for this... >
In addition to ncftp, I'm also seeing the same problem when building p7zip-9.13. I'm using gcc-4.4.3-r2, with a grsec kernel: x86_64-pc-linux-gnu-g++ -m64 -march=native -O3 -pipe -pipe -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -DNDEBUG -D_REENTRANT -DENV_UNIX -D_7ZIP_LARGE_PAGES -DBREAK_HANDLER -DUNICODE -D_UNICODE -c -I. -I../../../myWindows -I../../../ -I../../../include_windows ../../UI/Console/BenchCon.cpp x86_64-pc-linux-gnu-g++: Internal error: Segmentation fault (program cc1plus) Please submit a full bug report. See <http://bugs.gentoo.org/> for instructions. make[1]: *** [BenchCon.o] Error 1 But as comment #9 suggested, if I disable RANDMMAP on cc1plus, then p7zip builds successfully.
Created attachment 245224 [details, diff] add use pch add use pch so it can be disable. we have pch masked on the hardened profile.
@DC can you make a bug report for p7zip it have the same prob pre compiles headers
(In reply to comment #13) > (In reply to comment #11) > > Can somebody please reopen this thing? It's far from resolved and I got news. I > > talked to Mike Gleason about this, and he pointed me to the fact that the > > ebuild script is what triggers the segfault. That is, when you just compile the > > thing manually by ./configure; make; right from the archive, the segfault is > > never triggered. > > Er, is that what he said would happen or did you actually test this? We could > have a sandbox problem here - I don't see anything else between the kernel and > the shell. > No, he just made me try to narrow it down by manually compiling a single source file, which didn't segfault. So I tried compiling the whole thing vanilla from the .tar.bz2, which also worked fine even with RANDMMAP enabled in cc1.
(In reply to comment #15) > Created an attachment (id=245224) [details] > add use pch > > add use pch so it can be disable. > we have pch masked on the hardened profile. > Added to 3.2.4.1 without revision bump. If that does the trick then I guess this bug can be closed now. Thanks everyone!
Sorry... but are you adding workarounds to single packages for a bug in the compiler, exercised when running under hardened kernel? Given that PCH is a build-time feature that does NOT change the results, simply disable PCH when noticing a hardened kernel, rather than link it to the profile, and work on finding the real cause of problems.
(In reply to comment #19) > Sorry... but are you adding workarounds to single packages for a bug in the > compiler, exercised when running under hardened kernel? > > Given that PCH is a build-time feature that does NOT change the results, simply > disable PCH when noticing a hardened kernel, rather than link it to the > profile, and work on finding the real cause of problems. No, you are hijacking a bug reported about ncftp. File your own bug reports, please, and add them to a tracker. Hint: This isn't the tracker. Hint #2: Look at the Summary.
Thank you.
No, I'm reopening a bug which the ChangeLog reports as being "fixed" by adding a pch USE flag. You're not going to make many friends among QA and toolchain by removing CC and closing without even trying to explain your point about this being a bug _for_ ncftp rather than a general bug for the hardened compiler. And it's not something that you want a tracker about. So that you know, if package foo does not build with a GCC because it causes ICE, the bug is _with the compiler_ and not with the package itself. You might want to workaround it on the package but _the fix goes in the compiler_.
zorry, representing hardened@, provided a patch along with a rationale, which I gladly accepted, having little personal interest in either hardened kernels or precompiled headers. Oh, and I don't like the "personal" angle about making friends. We're here to solve an issue with the hardened toolchain? OK, knock yourself out. :)
(In reply to comment #23) > zorry, representing hardened@, provided a patch along with a rationale, which I > gladly accepted, having little personal interest in either hardened kernels or > precompiled headers. > > Oh, and I don't like the "personal" angle about making friends. We're here to > solve an issue with the hardened toolchain? OK, knock yourself out. :) > Can we please not forget that this not an issue *with the hardened toolchain*, but with a NON-hardened toolchain running under a hardened kernel? In fact, when using the hardened toolchain, everything works fine. I'd suppose that's an important point when looking for how to fix gcc. BTW, how do you suggest to proceed with this? Anyone looking into the gcc cause of this yet?
hardened kernel killing a non-hardened process does not mean the program in question is broken. the hardened kernels are known to break POSIX semantics in cases where security is considered more important than functionality.
*** Bug 335757 has been marked as a duplicate of this bug. ***
Created attachment 245878 [details, diff] check for host enable pax This patch check if the host have pax enable in the kernel and disable precomiledheaders.
Created attachment 245884 [details, diff] check for host enable pax inproved patch
bt from gdb with some pch test. Program received signal SIGSEGV, Segmentation fault. linemap_lookup (set=0x2b9fc8c8000, line=91) at /var/tmp/portage/sys-devel/gcc-4.4.4-r1/work/gcc-4.4.4/libcpp/line-map.c:276 276 mn = set->cache; (gdb) bt #0 linemap_lookup (set=0x2b9fc8c8000, line=91) at /var/tmp/portage/sys-devel/gcc-4.4.4-r1/work/gcc-4.4.4/libcpp/line-map.c:276 #1 0x00000000004d8fec in diagnostic_report_current_module (context=0xf4c6c0) at /var/tmp/portage/sys-devel/gcc-4.4.4-r1/work/gcc-4.4.4/gcc/diagnostic.c:236 #2 0x00000000004d9129 in diagnostic_report_current_function (context=0x2b9fc8c8000, diagnostic=0x5b) at /var/tmp/portage/sys-devel/gcc-4.4.4-r1/work/gcc-4.4.4/gcc/diagnostic.c:218 #3 0x00000000004d94e9 in default_diagnostic_starter (context=0x2b9fc8c8000, diagnostic=0x5b) at /var/tmp/portage/sys-devel/gcc-4.4.4-r1/work/gcc-4.4.4/gcc/diagnostic.c:263 #4 0x00000000004d8188 in diagnostic_report_diagnostic (context=0xf4c6c0, diagnostic=0x392d6cb07f0) at /var/tmp/portage/sys-devel/gcc-4.4.4-r1/work/gcc-4.4.4/gcc/diagnostic.c:403 #5 0x00000000004d8706 in fatal_error (gmsgid=<value optimized out>) at /var/tmp/portage/sys-devel/gcc-4.4.4-r1/work/gcc-4.4.4/gcc/diagnostic.c:640 #6 0x0000000000574636 in gt_pch_restore (f=0x1007770) at /var/tmp/portage/sys-devel/gcc-4.4.4-r1/work/gcc-4.4.4/gcc/ggc-common.c:576 #7 0x000000000045627c in c_common_read_pch (pfile=0xff1d00, name=<value optimized out>, fd=<value optimized out>, orig_name=<value optimized out>) at /var/tmp/portage/sys-devel/gcc-4.4.4-r1/work/gcc-4.4.4/gcc/c-pch.c:420 #8 0x0000000000a61098 in should_stack_file (pfile=0xff1d00, file=0x10046b0, import=0 '\000') at /var/tmp/portage/sys-devel/gcc-4.4.4-r1/work/gcc-4.4.4/libcpp/files.c:710 #9 _cpp_stack_file (pfile=0xff1d00, file=0x10046b0, import=0 '\000') at /var/tmp/portage/sys-devel/gcc-4.4.4-r1/work/gcc-4.4.4/libcpp/files.c:795 #10 0x0000000000a57f34 in do_include_common (pfile=0xff1d00, type=IT_INCLUDE)
Comment on attachment 245884 [details, diff] check for host enable pax i dont think this is the way to go
guys, the PCH problem is due to several factors. 1. gcc's PCH approach cannot relocate the PCHs at runtime so they must be loaded at the same address they were generated at. 2. gcc doesn't use MAP_FIXED to map the PCHs. instead it tries to use 'hopefully free' address space ranges (per arch, see gcc/config/host-linux.c) and assumes that a hinted mmap address (without MAP_FIXED) will be honored exactly somehow (POSIX never guaranteed anything like that, that's why MAP_FIXED exists in the first place). 3. PaX/ASLR gladly ignores any hints in !MAP_FIXED mmap requests (allowed by POSIX and common sense). now what happens here is that gcc detects that the hinted mmap wasn't honored in gt_pch_restore and calls fatal_error which later segfaults on accessing a seemingly trashed line_table pointer. in my debugging it seems to point at the PCH's address range, except at the time the PCH wasn't mapped at all (gcc was trying to report that error in fact, somewhat ironically ;), so it's likely a logic bug somewhere in gcc, worth a report to upstream i think). as for the higher level problem, it can be solved at each step described above, with different costs/benefits. fixing 1 is probably a big undertaking and probably only the gcc guys can pull it off anyway, so it's not going to happen. fixing 2 cannot be done in general since nothing really guarantees the existence of any particular address space hole short of the application ensuring it itself (but then no extra mmap would be needed). what can be done is to choose better addresses (say, the i386 one won't work under SEGMEXEC) and use MAP_FIXED (by checking /proc/pid/maps first for any undesired collisions). this requires some coding but nothing too hard (e.g., glibc has such maps parsing code in it already i think) but i'm not sure the gcc people would accept such a patch. fixing 3 is not going to happen since it'd reduce security and that's why people are using PaX in the first place, i.e., one might as well just disable ASLR on the affected gcc binaries instead (which is actually not a bad idea, it won't affect security and is the cheapest solution for gentoo i think). @spanky: if you know of any actual POSIX breakage, let me know 'cos it's a bug ;).
Upstream bug http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52194
Fixed in revision 1.515 of toolchain.eclass to pax mark cc1 and cc1plus with -r. Will wait for upstream for a real fix.
*** Bug 427248 has been marked as a duplicate of this bug. ***
*** Bug 425524 has been marked as a duplicate of this bug. ***
