Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 301299 (PR52194) - sys-devel/gcc: building with PCH will fail when using hardened kernel
Summary: sys-devel/gcc: building with PCH will fail when using hardened kernel
Status: RESOLVED UPSTREAM
Alias: PR52194
Product: Gentoo Linux
Classification: Unclassified
Component: Current packages (show other bugs)
Hardware: AMD64 Linux
: High normal (vote)
Assignee: The Gentoo Linux Hardened Team
URL: http://forums.grsecurity.net/viewtopi...
Whiteboard:
Keywords:
: 335757 425524 (view as bug list)
Depends on: 278790
Blocks:
  Show dependency tree
 
Reported: 2010-01-17 18:42 UTC by pjank
Modified: 2016-01-18 09:52 UTC (History)
9 users (show)

See Also:
Package list:
Runtime testing required: ---


Attachments
build.log (build.log,17.10 KB, text/plain)
2010-01-17 18:43 UTC, pjank
Details
environment (environment,86.06 KB, text/plain)
2010-01-17 18:43 UTC, pjank
Details
add use pch (ncftp_no-pch.ebuild.patch,863 bytes, patch)
2010-08-29 13:23 UTC, Magnus Granberg
Details | Diff
check for host enable pax (ncftp_no-pch.ebuild.patch,979 bytes, patch)
2010-09-03 15:29 UTC, Magnus Granberg
Details | Diff
check for host enable pax (ncftp_no-pch.ebuild.patch,945 bytes, patch)
2010-09-03 15:39 UTC, Magnus Granberg
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description pjank 2010-01-17 18:42:13 UTC
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
Comment 1 pjank 2010-01-17 18:43:00 UTC
Created attachment 216753 [details]
build.log
Comment 2 pjank 2010-01-17 18:43:32 UTC
Created attachment 216754 [details]
environment
Comment 3 Patrick Lauer gentoo-dev 2010-01-17 21:47:47 UTC
That seems to be a problem with your toolchain.
You could try re-emerging gcc, but I doubt that'll have any effect ...
Comment 4 Jeroen Roovers gentoo-dev 2010-01-19 03:45:37 UTC
I guess it's the combination of a kernel with grsec and userland without grsec.
Comment 5 pjank 2010-01-19 17:17:06 UTC
(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?


Comment 6 Arnim Eijkhoudt 2010-05-21 19:03:28 UTC
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.
Comment 7 Arnim Eijkhoudt 2010-05-21 19:04:33 UTC
Addendum: sorry I meant to say that I *DO* have hardened in my USE flags (doh).
Comment 8 Victor Mataré 2010-06-28 15:02:21 UTC
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?
Comment 9 Victor Mataré 2010-06-30 01:13:58 UTC
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?
Comment 10 Arnim Eijkhoudt 2010-07-31 20:34:50 UTC
This bug is still present in the current ncftp-3.2.4.1 ebuild in portage. What more info is needed?
Comment 11 Victor Mataré 2010-08-14 04:06:56 UTC
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...
Comment 12 pjank 2010-08-14 06:52:32 UTC
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.
Comment 13 Jeroen Roovers gentoo-dev 2010-08-15 23:03:18 UTC
(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...
> 

Comment 14 DC 2010-08-29 06:48:52 UTC
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.
Comment 15 Magnus Granberg gentoo-dev 2010-08-29 13:23:48 UTC
Created attachment 245224 [details, diff]
add use pch

add use pch so it can be disable.
we have pch masked on the hardened profile.
Comment 16 Magnus Granberg gentoo-dev 2010-08-29 14:00:28 UTC
@DC can you make a bug report for p7zip it have the same prob
pre compiles headers
Comment 17 Victor Mataré 2010-08-29 18:51:56 UTC
(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. 
Comment 18 Jeroen Roovers gentoo-dev 2010-08-30 03:07:15 UTC
(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!
Comment 19 Diego Elio Pettenò (RETIRED) gentoo-dev 2010-08-30 11:38:31 UTC
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.
Comment 20 Jeroen Roovers gentoo-dev 2010-08-30 14:17:01 UTC
(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.
Comment 21 Jeroen Roovers gentoo-dev 2010-08-30 14:17:15 UTC
Thank you.
Comment 22 Diego Elio Pettenò (RETIRED) gentoo-dev 2010-08-30 14:42:10 UTC
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_.
Comment 23 Jeroen Roovers gentoo-dev 2010-08-30 18:20:54 UTC
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. :)
Comment 24 Victor Mataré 2010-08-31 00:17:00 UTC
(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?
Comment 25 SpanKY gentoo-dev 2010-08-31 05:00:03 UTC
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.
Comment 26 Diego Elio Pettenò (RETIRED) gentoo-dev 2010-09-03 13:17:08 UTC
*** Bug 335757 has been marked as a duplicate of this bug. ***
Comment 27 Magnus Granberg gentoo-dev 2010-09-03 15:29:10 UTC
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.
Comment 28 Magnus Granberg gentoo-dev 2010-09-03 15:39:19 UTC
Created attachment 245884 [details, diff]
check for host enable pax

inproved patch
Comment 29 Magnus Granberg gentoo-dev 2010-09-03 16:28:04 UTC
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 30 SpanKY gentoo-dev 2010-09-04 23:35:11 UTC
Comment on attachment 245884 [details, diff]
check for host enable pax

i dont think this is the way to go
Comment 31 PaX Team 2010-09-22 22:55:06 UTC
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 ;).
Comment 32 Magnus Granberg gentoo-dev 2012-02-09 21:45:04 UTC
Upstream bug http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52194
Comment 33 Magnus Granberg gentoo-dev 2012-02-12 14:51:16 UTC
Fixed in revision 1.515 of toolchain.eclass to pax mark cc1 and cc1plus
with -r. Will wait for upstream for a real fix.
Comment 34 Magnus Granberg gentoo-dev 2012-07-19 19:54:29 UTC
*** Bug 427248 has been marked as a duplicate of this bug. ***
Comment 35 SpanKY gentoo-dev 2016-01-18 09:52:50 UTC
*** Bug 425524 has been marked as a duplicate of this bug. ***