Created attachment 388780 [details] sys-libs:glibc-2.20:20141107-104746.log.gz within a chroot (~amd64 hardened) of a host (amd64 hardened) - testedboth with -j6 and -j1, details : tinderbox@tor-relay ~ $ sudo /mnt/qa/tinderbox/chr.sh amd64-hardened tinderbox amd64-hardened ~ $ emerge --info sys-libs/glibc Portage 2.2.14 (python 3.3.5-final-0, hardened/linux/amd64, gcc-4.8.3, glibc-2.19-r1, 3.17.2-hardened x86_64) ================================================================= System Settings ================================================================= System uname: Linux-3.17.2-hardened-x86_64-Intel-R-_Core-TM-_i7-3770_CPU_@_3.40GHz-with-gentoo-2.2 KiB Mem: 16166892 total, 4784080 free KiB Swap: 16777212 total, 16766660 free Timestamp of tree: Fri, 07 Nov 2014 09:45:02 +0000 ld GNU ld (Gentoo 2.24 p1.4) 2.24 app-shells/bash: 4.3_p30 dev-lang/perl: 5.20.1-r2 dev-lang/python: 2.7.8, 3.3.5-r1 dev-util/pkgconfig: 0.28-r2 sys-apps/baselayout: 2.2 sys-apps/openrc: 0.13.2 sys-apps/sandbox: 2.6-r1 sys-devel/autoconf: 2.69 sys-devel/automake: 1.14.1 sys-devel/binutils: 2.24-r3 sys-devel/gcc: 4.8.3 sys-devel/gcc-config: 1.8 sys-devel/libtool: 2.4.3 sys-devel/make: 4.1-r1 sys-kernel/linux-headers: 3.17-r1 (virtual/os-headers) sys-libs/glibc: 2.19-r1 Repositories: gentoo ACCEPT_KEYWORDS="amd64 ~amd64" ACCEPT_LICENSE="*" 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/gconf /etc/gentoo-release /etc/sandbox.d /etc/terminfo" CXXFLAGS="-O2 -pipe" DISTDIR="/usr/portage/distfiles" EMERGE_DEFAULT_OPTS="--nospinner --tree --quiet-build --deep" FCFLAGS="-O2 -pipe" FEATURES="assume-digests binpkg-logs config-protect-if-modified distlocks ebuild-locks fixlafiles merge-sync news parallel-fetch preserve-libs protect-owned sandbox sfperms strict unknown-features-warn unmerge-logs unmerge-orphans userfetch userpriv usersandbox usersync xattr" FFLAGS="-O2 -pipe" GENTOO_MIRRORS="http://mirror.leaseweb.com/gentoo/ http://ftp.uni-erlangen.de/pub/mirrors/gentoo http://ftp-stud.hs-esslingen.de/pub/Mirrors/gentoo/ http://gd.tuwien.ac.at/opsys/linux/gentoo/" LANG="en_US.utf8" LDFLAGS="-Wl,-O1 -Wl,--as-needed" MAKEOPTS="-j1" PKGDIR="/usr/portage/packages" PORTAGE_CONFIGROOT="/" PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --omit-dir-times --compress --force --whole-file --delete --stats --human-readable --timeout=180 --exclude=/distfiles --exclude=/local --exclude=/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="" SYNC="rsync://rsync.de.gentoo.org/gentoo-portage" USE="acl amd64 berkdb bindist bzip2 cli cracklib crypt cxx dri gdbm hardened iconv ipv6 justify mbox mmx modules multilib ncurses nls nptl openmp pam pax_kernel pcre readline session sse sse2 ssl tcpd unicode urandom xattr xtpax zlib" ABI_X86="64" 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" APACHE2_MODULES="authn_core authz_core socache_shmcb unixd 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 cgi cgid 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" CALLIGRA_FEATURES="kexi words flow plan sheets stage tables krita karbon braindump author" CAMERAS="ptp2" COLLECTD_PLUGINS="df interface irq load memory rrdtool swap syslog" ELIBC="glibc" GPSD_PROTOCOLS="ashtech aivdm earthmate evermore fv18 garmin garmintxt gpsclock itrax mtk3301 nmea ntrip navcom oceanserver oldstyle oncore rtcm104v2 rtcm104v3 sirf superstar2 timing tsip tripmate tnt ublox ubx" INPUT_DEVICES="keyboard mouse evdev" KERNEL="linux" LCD_DEVICES="bayrad cfontz cfontz633 glk hd44780 lb216 lcdm001 mtxorb ncurses text" LIBREOFFICE_EXTENSIONS="presenter-console presenter-minimizer" OFFICE_IMPLEMENTATION="libreoffice" PHP_TARGETS="php5-5" PYTHON_SINGLE_TARGET="python2_7" PYTHON_TARGETS="python2_7 python3_3" RUBY_TARGETS="ruby19 ruby20" USERLAND="GNU" VIDEO_CARDS="fbdev glint intel mach64 mga nouveau nv r128 radeon savage sis tdfx trident vesa via vmware dummy v4l" 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, INSTALL_MASK, LC_ALL, PORTAGE_BUNZIP2_COMMAND, PORTAGE_COMPRESS, PORTAGE_COMPRESS_FLAGS, PORTAGE_RSYNC_EXTRA_OPTS, USE_PYTHON ================================================================= Package Settings ================================================================= sys-libs/glibc-2.19-r1 was built with the following: USE="hardened (multilib) -debug -gd -nscd -profile (-selinux) -suid -systemtap -vanilla" ABI_X86="64" CFLAGS="-pipe -O2 -fno-strict-aliasing -fno-stack-protector" CXXFLAGS="-pipe -O2 -fno-strict-aliasing -fno-stack-protector"
FWIW within /var/log/message of the host I got : Nov 7 12:20:00 tor-relay kernel: grsec: From 85.177.163.159: Segmentation fault occurred at (nil) in /mnt/qa/tinderbox/amd64-hardened/var/tmp/portage/sys-libs/glibc-2.20/work/build-x86-x86_64-pc-linux-gnu-nptl/elf/sln[sln:26542] uid/euid:0/0 gid/egid:0/0, parent /mnt/qa/tinderbox/amd64-hardened/usr/bin/gmake[make:26541] uid/euid:0/0 gid/egid:0/0 Nov 7 12:20:00 tor-relay kernel: grsec: From 85.177.163.159: denied resource overstep by requesting 4096 for RLIMIT_CORE against limit 0 for /mnt/qa/tinderbox/amd64-hardened/var/tmp/portage/sys-libs/glibc-2.20/work/build-x86-x86_64-pc-linux-gnu-nptl/elf/sln[sln:26542] uid/euid:0/0 gid/egid:0/0, parent /mnt/qa/tinderbox/amd64-hardened/usr/bin/gmake[make:26541] uid/euid:0/0 gid/egid:0/0
Same here, thanks for reporting. argus glibc-2.20 # /var/tmp/portage/sys-libs/glibc-2.20/work/build-x86-x86_64-pc-linux-gnu-nptl/elf/sln /var/tmp/portage/sys-libs/glibc-2.20/work/build-x86-x86_64-pc-linux-gnu-nptl/elf/symlink.list Segmentation fault argus glibc-2.20 # paxctl-ng -v /var/tmp/portage/sys-libs/glibc-2.20/work/build-x86-x86_64-pc-linux-gnu-nptl/elf/sln /var/tmp/portage/sys-libs/glibc-2.20/work/build-x86-x86_64-pc-linux-gnu-nptl/elf/sln: PT_PAX : -e--- XATTR_PAX : not found argus glibc-2.20 # paxctl-ng -pemrs /var/tmp/portage/sys-libs/glibc-2.20/work/build-x86-x86_64-pc-linux-gnu-nptl/elf/sln argus glibc-2.20 # paxctl-ng -v /var/tmp/portage/sys-libs/glibc-2.20/work/build-x86-x86_64-pc-linux-gnu-nptl/elf/sln /var/tmp/portage/sys-libs/glibc-2.20/work/build-x86-x86_64-pc-linux-gnu-nptl/elf/sln: PT_PAX : pemrs XATTR_PAX : pemrs argus glibc-2.20 # /var/tmp/portage/sys-libs/glibc-2.20/work/build-x86-x86_64-pc-linux-gnu-nptl/elf/sln /var/tmp/portage/sys-libs/glibc-2.20/work/build-x86-x86_64-pc-linux-gnu-nptl/elf/symlink.list Segmentation fault argus glibc-2.20 # gdb /var/tmp/portage/sys-libs/glibc-2.20/work/build-x86-x86_64-pc-linux-gnu-nptl/elf/sln GNU gdb (Gentoo 7.8.1 vanilla) 7.8.1 Copyright (C) 2014 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "x86_64-pc-linux-gnu". Type "show configuration" for configuration details. For bug reporting instructions, please see: <http://bugs.gentoo.org/>. Find the GDB manual and other documentation resources online at: <http://www.gnu.org/software/gdb/documentation/>. For help, type "help". Type "apropos word" to search for commands related to "word"... Reading symbols from /var/tmp/portage/sys-libs/glibc-2.20/work/build-x86-x86_64-pc-linux-gnu-nptl/elf/sln...done. (gdb) run /var/tmp/portage/sys-libs/glibc-2.20/work/build-x86-x86_64-pc-linux-gnu-nptl/elf/symlink.list Starting program: /var/tmp/portage/sys-libs/glibc-2.20/work/build-x86-x86_64-pc-linux-gnu-nptl/elf/sln /var/tmp/portage/sys-libs/glibc-2.20/work/build-x86-x86_64-pc-linux-gnu-nptl/elf/symlink.list warning: Cannot call inferior functions, Linux kernel PaX protection forbids return to non-executable pages! Program received signal SIGSEGV, Segmentation fault. 0x08049921 in __libc_setup_tls (tcbsize=1216, tcbalign=64) at libc-tls.c:200 200 const char *lossage = TLS_INIT_TP ((char *) tlsblock + tcb_offset); (gdb) bt #0 0x08049921 in __libc_setup_tls (tcbsize=1216, tcbalign=64) at libc-tls.c:200 #1 0x08049adf in __pthread_initialize_minimal () at libc-tls.c:256 #2 0x080494e7 in __libc_start_main (main=0x80487e0 <main>, argc=2, argv=0xffffd5f4, init=0x8049af0 <__libc_csu_init>, fini=0x8049ba0 <__libc_csu_fini>, rtld_fini=0x0, stack_end=0xffffd5ec) at libc-start.c:184 #3 0x08048d55 in _start () at ../sysdeps/i386/start.S:102 (gdb)
It is not just a kernel PAX issue as I had this same problem (with gdb showing the same stack trace) on a system with gentoo-sources-3.17.2 kernel with with a hardened toolset ie the hardened profile but non-hardened kernel) . So I I think it is the toolset rather than grsec/pax causing the failure.
I could install glibc-2.20 on my hardened (but with a vanilla kernel) ~amd64 system without problems. However, I run into this segfault on my ~x86 system (also hardend toolchain with vanilla kernel).
BTW I fear that 2.20 broke a ~x86 chroot image here completely in the ability of build.sh to unpack an archive - I had to restore a backup the chroot image (heh - worked !!!)
FWIW, same issue here on multiple boxes, all amd64: - 2 with hardened profile + hardened-sources kernel, grsec enabled - 2 with hardened profile + gentoo-sources kernel (i.e. no grsec) On all of them, glibc-2.20 fails to build with "Makefile:104: recipe for target 'install-symbolic-link' failed", and /var/tmp/portage/sys-libs/glibc-2.20/work/build-x86-x86_64-pc-linux-gnu-nptl/elf/sln segfaulting. I do not think I have any boxes not using a hardened profile + toolchain. I'll attach a build.log from one of the hardened-sources kernels and one of the gentoo-sources kernels, but they look substantially similar to each other, and to what Toralf submitted.
Created attachment 388884 [details] build.log on a box w/hardened profile but standard gentoo-sources kernel, no grsec
Created attachment 388886 [details] build.log on a box w/hardened profile and grsec kernel, most grsec features on
Vapier do you have any clue on what change on the tls code for we do some patching on the tls code. The inittls-nosysenter patch.
thanks guys, but we don't need anymore build logs at this point
(In reply to SpanKY from comment #10) > thanks guys, but we don't need anymore build logs at this point The problem is triggered by the hardened gcc-4.8.3 when installing the x86 stuff on a multilib amd64 hardened systems. If you switch to x86_64-pc-linux-gnu-4.8.3-vanilla with gcc-config, you don't hit it. I'll try to narrow it further.
(In reply to Anthony Basile from comment #11) > (In reply to SpanKY from comment #10) > > thanks guys, but we don't need anymore build logs at this point > > The problem is triggered by the hardened gcc-4.8.3 when installing the x86 > stuff on a multilib amd64 hardened systems. If you switch to > x86_64-pc-linux-gnu-4.8.3-vanilla with gcc-config, you don't hit it. I'll > try to narrow it further. My bets would then be either stackcheck (although the only assembly I saw there was a syscall) or some regression on the compiler. blueness how are you testing the issue? I can try with 4.7.3 on this machine if you tell me how to.
Tests with gcc-4.7.3 show exactly the same results in dmesg. So I doubt this is caused by stack check nor a regression :( [251485.870489] grsec: Segmentation fault occurred at (nil) in /var/tmp/portage/sys-libs/glibc-2.20/work/build-x86-x86_64-pc-linux-gnu-nptl/csu/tst-empty[tst-empty:26101] uid/euid:250/250 gid/egid:250/250, parent /bin/env[env:26100] uid/euid:250/250 gid/egid:250/250 [251485.870527] grsec: denied resource overstep by requesting 4096 for RLIMIT_CORE against limit 0 for /var/tmp/portage/sys-libs/glibc-2.20/work/build-x86-x86_64-pc-linux-gnu-nptl/csu/tst-empty[tst-empty:26101] uid/euid:250/250 gid/egid:250/250, parent /bin/env[env:26100] uid/euid:250/250 gid/egid:250/250 [251527.665796] grsec: Segmentation fault occurred at (nil) in /var/tmp/portage/sys-libs/glibc-2.20/work/build-x86-x86_64-pc-linux-gnu-nptl/localedata/bug-setlocale1-static[bug-setlocale1-:28363] uid/euid:250/250 gid/egid:250/250, parent /bin/env[env:28362] uid/euid:250/250 gid/egid:250/250 [251527.665834] grsec: denied resource overstep by requesting 4096 for RLIMIT_CORE against limit 0 for /var/tmp/portage/sys-libs/glibc-2.20/work/build-x86-x86_64-pc-linux-gnu-nptl/localedata/bug-setlocale1-static[bug-setlocale1-:28363] uid/euid:250/250 gid/egid:250/250, parent /bin/env[env:28362] uid/euid:250/250 gid/egid:250/250 [251528.382685] grsec: Segmentation fault occurred at (nil) in /var/tmp/portage/sys-libs/glibc-2.20/work/build-x86-x86_64-pc-linux-gnu-nptl/localedata/tst-langinfo-static[tst-langinfo-st:28493] uid/euid:250/250 gid/egid:250/250, parent /bin/env[env:28492] uid/euid:250/250 gid/egid:250/250 [251528.382713] grsec: denied resource overstep by requesting 4096 for RLIMIT_CORE against limit 0 for /var/tmp/portage/sys-libs/glibc-2.20/work/build-x86-x86_64-pc-linux-gnu-nptl/localedata/tst-langinfo-static[tst-langinfo-st:28493] uid/euid:250/250 gid/egid:250/250, parent /bin/env[env:28492] uid/euid:250/250 gid/egid:250/250 [251674.037395] grsec: Segmentation fault occurred at (nil) in /var/tmp/portage/sys-libs/glibc-2.20/work/build-x86-x86_64-pc-linux-gnu-nptl/math/test-fpucw-static[test-fpucw-stat:7092] uid/euid:250/250 gid/egid:250/250, parent /bin/env[env:7091] uid/euid:250/250 gid/egid:250/250 [251674.037433] grsec: denied resource overstep by requesting 4096 for RLIMIT_CORE against limit 0 for /var/tmp/portage/sys-libs/glibc-2.20/work/build-x86-x86_64-pc-linux-gnu-nptl/math/test-fpucw-static[test-fpucw-stat:7092] uid/euid:250/250 gid/egid:250/250, parent /bin/env[env:7091] uid/euid:250/250 gid/egid:250/250 [251674.214825] grsec: Segmentation fault occurred at (nil) in /var/tmp/portage/sys-libs/glibc-2.20/work/build-x86-x86_64-pc-linux-gnu-nptl/math/test-fpucw-ieee-static[test-fpucw-ieee:7106] uid/euid:250/250 gid/egid:250/250, parent /bin/env[env:7105] uid/euid:250/250 gid/egid:250/250 [251674.214862] grsec: denied resource overstep by requesting 4096 for RLIMIT_CORE against limit 0 for /var/tmp/portage/sys-libs/glibc-2.20/work/build-x86-x86_64-pc-linux-gnu-nptl/math/test-fpucw-ieee-static[test-fpucw-ieee:7106] uid/euid:250/250 gid/egid:250/250, parent /bin/env[env:7105] uid/euid:250/250 gid/egid:250/250 [251714.522898] grsec: Segmentation fault occurred at (nil) in /var/tmp/portage/sys-libs/glibc-2.20/work/build-x86-x86_64-pc-linux-gnu-nptl/stdlib/tst-secure-getenv[tst-secure-gete:7583] uid/euid:250/250 gid/egid:250/250, parent /bin/env[env:7582] uid/euid:250/250 gid/egid:250/250 [251714.522937] grsec: denied resource overstep by requesting 4096 for RLIMIT_CORE against limit 0 for /var/tmp/portage/sys-libs/glibc-2.20/work/build-x86-x86_64-pc-linux-gnu-nptl/stdlib/tst-secure-getenv[tst-secure-gete:7583] uid/euid:250/250 gid/egid:250/250, parent /bin/env[env:7582] uid/euid:250/250 gid/egid:250/250 [251753.759694] grsec: Segmentation fault occurred at (nil) in /var/tmp/portage/sys-libs/glibc-2.20/work/build-x86-x86_64-pc-linux-gnu-nptl/localedata/tst-langinfo-static[tst-langinfo-st:10221] uid/euid:250/250 gid/egid:250/250, parent /bin/env[env:10220] uid/euid:250/250 gid/egid:250/250 [251753.759732] grsec: denied resource overstep by requesting 4096 for RLIMIT_CORE against limit 0 for /var/tmp/portage/sys-libs/glibc-2.20/work/build-x86-x86_64-pc-linux-gnu-nptl/localedata/tst-langinfo-static[tst-langinfo-st:10221] uid/euid:250/250 gid/egid:250/250, parent /bin/env[env:10220] uid/euid:250/250 gid/egid:250/250 [251780.773516] grsec: Segmentation fault occurred at (nil) in /var/tmp/portage/sys-libs/glibc-2.20/work/build-x86-x86_64-pc-linux-gnu-nptl/dlfcn/tststatic[tststatic:14515] uid/euid:250/250 gid/egid:250/250, parent /bin/env[env:14514] uid/euid:250/250 gid/egid:250/250 [251780.773554] grsec: denied resource overstep by requesting 4096 for RLIMIT_CORE against limit 0 for /var/tmp/portage/sys-libs/glibc-2.20/work/build-x86-x86_64-pc-linux-gnu-nptl/dlfcn/tststatic[tststatic:14515] uid/euid:250/250 gid/egid:250/250, parent /bin/env[env:14514] uid/euid:250/250 gid/egid:250/250 [251781.251502] grsec: Segmentation fault occurred at (nil) in /var/tmp/portage/sys-libs/glibc-2.20/work/build-x86-x86_64-pc-linux-gnu-nptl/dlfcn/tststatic2[tststatic2:14535] uid/euid:250/250 gid/egid:250/250, parent /bin/env[env:14534] uid/euid:250/250 gid/egid:250/250 [251781.251542] grsec: denied resource overstep by requesting 4096 for RLIMIT_CORE against limit 0 for /var/tmp/portage/sys-libs/glibc-2.20/work/build-x86-x86_64-pc-linux-gnu-nptl/dlfcn/tststatic2[tststatic2:14535] uid/euid:250/250 gid/egid:250/250, parent /bin/env[env:14534] uid/euid:250/250 gid/egid:250/250 [251781.631498] grsec: Segmentation fault occurred at (nil) in /var/tmp/portage/sys-libs/glibc-2.20/work/build-x86-x86_64-pc-linux-gnu-nptl/dlfcn/tststatic3[tststatic3:14555] uid/euid:250/250 gid/egid:250/250, parent /bin/env[env:14554] uid/euid:250/250 gid/egid:250/250 [251781.631529] grsec: more alerts, logging disabled for 10 seconds [251836.862132] grsec: Segmentation fault occurred at (nil) in /var/tmp/portage/sys-libs/glibc-2.20/work/build-x86-x86_64-pc-linux-gnu-nptl/posix/tst-exec-static[tst-exec-static:16456] uid/euid:250/250 gid/egid:250/250, parent /bin/env[env:16455] uid/euid:250/250 gid/egid:250/250 [251836.862163] grsec: denied resource overstep by requesting 4096 for RLIMIT_CORE against limit 0 for /var/tmp/portage/sys-libs/glibc-2.20/work/build-x86-x86_64-pc-linux-gnu-nptl/posix/tst-exec-static[tst-exec-static:16456] uid/euid:250/250 gid/egid:250/250, parent /bin/env[env:16455] uid/euid:250/250 gid/egid:250/250 [251837.274869] grsec: Segmentation fault occurred at (nil) in /var/tmp/portage/sys-libs/glibc-2.20/work/build-x86-x86_64-pc-linux-gnu-nptl/posix/tst-spawn-static[tst-spawn-stati:16470] uid/euid:250/250 gid/egid:250/250, parent /bin/env[env:16469] uid/euid:250/250 gid/egid:250/250 [251837.274902] grsec: denied resource overstep by requesting 4096 for RLIMIT_CORE against limit 0 for /var/tmp/portage/sys-libs/glibc-2.20/work/build-x86-x86_64-pc-linux-gnu-nptl/posix/tst-spawn-static[tst-spawn-stati:16470] uid/euid:250/250 gid/egid:250/250, parent /bin/env[env:16469] uid/euid:250/250 gid/egid:250/250 [251854.263693] grsec: Segmentation fault occurred at (nil) in /var/tmp/portage/sys-libs/glibc-2.20/work/build-x86-x86_64-pc-linux-gnu-nptl/gmon/tst-profile-static[tst-profile-sta:17900] uid/euid:250/250 gid/egid:250/250, parent /bin/env[env:17899] uid/euid:250/250 gid/egid:250/250 [251854.263731] grsec: denied resource overstep by requesting 4096 for RLIMIT_CORE against limit 0 for /var/tmp/portage/sys-libs/glibc-2.20/work/build-x86-x86_64-pc-linux-gnu-nptl/gmon/tst-profile-static[tst-profile-sta:17900] uid/euid:250/250 gid/egid:250/250, parent /bin/env[env:17899] uid/euid:250/250 gid/egid:250/250 [251908.067833] grsec: Segmentation fault occurred at (nil) in /var/tmp/portage/sys-libs/glibc-2.20/work/build-x86-x86_64-pc-linux-gnu-nptl/nptl/tst-locale1[tst-locale1:19848] uid/euid:250/250 gid/egid:250/250, parent /bin/env[env:19847] uid/euid:250/250 gid/egid:250/250 [251908.067862] grsec: denied resource overstep by requesting 4096 for RLIMIT_CORE against limit 0 for /var/tmp/portage/sys-libs/glibc-2.20/work/build-x86-x86_64-pc-linux-gnu-nptl/nptl/tst-locale1[tst-locale1:19848] uid/euid:250/250 gid/egid:250/250, parent /bin/env[env:19847] uid/euid:250/250 gid/egid:250/250 [251908.387835] grsec: Segmentation fault occurred at (nil) in /var/tmp/portage/sys-libs/glibc-2.20/work/build-x86-x86_64-pc-linux-gnu-nptl/nptl/tst-locale2[tst-locale2:19863] uid/euid:250/250 gid/egid:250/250, parent /bin/env[env:19862] uid/euid:250/250 gid/egid:250/250 [251908.387875] grsec: denied resource overstep by requesting 4096 for RLIMIT_CORE against limit 0 for /var/tmp/portage/sys-libs/glibc-2.20/work/build-x86-x86_64-pc-linux-gnu-nptl/nptl/tst-locale2[tst-locale2:19863] uid/euid:250/250 gid/egid:250/250, parent /bin/env[env:19862] uid/euid:250/250 gid/egid:250/250 [251919.419593] grsec: Segmentation fault occurred at (nil) in /var/tmp/portage/sys-libs/glibc-2.20/work/build-x86-x86_64-pc-linux-gnu-nptl/nptl/tst-stackguard1-static[tst-stackguard1:20256] uid/euid:250/250 gid/egid:250/250, parent /bin/env[env:20255] uid/euid:250/250 gid/egid:250/250 [251919.419643] grsec: denied resource overstep by requesting 4096 for RLIMIT_CORE against limit 0 for /var/tmp/portage/sys-libs/glibc-2.20/work/build-x86-x86_64-pc-linux-gnu-nptl/nptl/tst-stackguard1-static[tst-stackguard1:20256] uid/euid:250/250 gid/egid:250/250, parent /bin/env[env:20255] uid/euid:250/250 gid/egid:250/250 [251919.775066] grsec: Segmentation fault occurred at (nil) in /var/tmp/portage/sys-libs/glibc-2.20/work/build-x86-x86_64-pc-linux-gnu-nptl/nptl/tst-cancel21-static[tst-cancel21-st:20270] uid/euid:250/250 gid/egid:250/250, parent /bin/env[env:20269] uid/euid:250/250 gid/egid:250/250 [251919.775104] grsec: denied resource overstep by requesting 4096 for RLIMIT_CORE against limit 0 for /var/tmp/portage/sys-libs/glibc-2.20/work/build-x86-x86_64-pc-linux-gnu-nptl/nptl/tst-cancel21-static[tst-cancel21-st:20270] uid/euid:250/250 gid/egid:250/250, parent /bin/env[env:20269] uid/euid:250/250 gid/egid:250/250 [251920.557222] grsec: Segmentation fault occurred at (nil) in /var/tmp/portage/sys-libs/glibc-2.20/work/build-x86-x86_64-pc-linux-gnu-nptl/nptl/tst-cond8-static[tst-cond8-stati:20294] uid/euid:250/250 gid/egid:250/250, parent /bin/env[env:20293] uid/euid:250/250 gid/egid:250/250 [251920.557251] grsec: more alerts, logging disabled for 10 seconds p
The problem is in INTERNAL_SYSCALL_NOSYSENTER which avoids sysenter on i386 for brk. Avoiding sysenter is needed for a PIC compile of glibc because then syscalls need thread local storage initialized which is not available before you do a brk(). This approach was broken by the following commit: https://sourceware.org/git/gitweb.cgi?p=glibc.git;h=9570bc53fcc11d3cfe028989e611266e8d55bd09 That commit avoided some hand written asm so that memory tracking tools like valgrind don't loose track of the stack. All very nice but it breaks the above. I'm trying to figure out how to fix this.
Created attachment 388960 [details, diff] Patch making the TLS initialization avoiding the problematic sysenter After some fixing and thanks to blueness pointers I have managed to get this patch which seems to be preventing the segfaults on the glibc tests.
(In reply to Francisco Blas Izquierdo Riera from comment #15) > Created attachment 388960 [details, diff] [details, diff] > Patch making the TLS initialization avoiding the problematic sysenter > > After some fixing and thanks to blueness pointers I have managed to get this > patch which seems to be preventing the segfaults on the glibc tests. Tested and it works. Nice job klondike! We should probably coalesce your patch and Kevin's.
Well I was doing some reading yesterday, maybe we can improve the patches a lot if we move the sysenter point to a global variable instead of TLS. I think it would even improve efficiency. But I can't shake the feeling they are using TLS for a reason even though at least on x86 the sysenter value is constant along all the process.
*** Bug 528856 has been marked as a duplicate of this bug. ***
(In reply to Francisco Blas Izquierdo Riera from comment #17) > Well I was doing some reading yesterday, maybe we can improve the patches a > lot if we move the sysenter point to a global variable instead of TLS. I > think it would even improve efficiency. > > But I can't shake the feeling they are using TLS for a reason even though at > least on x86 the sysenter value is constant along all the process. Sounds like this would not be thread safe.
the current patch needs a bit of tidying up, so i'll see about that and merging this one in the process
should be all set now in the tree; thanks for the report! Commit message: Fix by Francisco Blas Izquierdo Riera for crash on hardened in early TLS init code http://sources.gentoo.org/sys-libs/glibc/files/2.20/glibc-2.20-hardened-inittls-nosysenter.patch?rev=1.1 http://sources.gentoo.org/sys-libs/glibc/glibc-2.20.ebuild?r1=1.5&r2=1.6 http://sources.gentoo.org/sys-libs/glibc/glibc-9999.ebuild?r1=1.26&r2=1.27
could you guys double check to make sure i didn't screw anything up ? i have a hardened system, but it's stable/production, so can't experiment with things like glibc replacement :).
(In reply to SpanKY from comment #22) > could you guys double check to make sure i didn't screw anything up ? i > have a hardened system, but it's stable/production, so can't experiment with > things like glibc replacement :). I was not part of the initial report in this thread, though I did experience the same issue as comment #6. I can confirm that this issue has been resolved by the commits mentioned in comment #21. Thank you.
(In reply to Francisco Blas Izquierdo Riera from comment #17) > Well I was doing some reading yesterday, maybe we can improve the patches a > lot if we move the sysenter point to a global variable instead of TLS. I > think it would even improve efficiency. > > But I can't shake the feeling they are using TLS for a reason even though at > least on x86 the sysenter value is constant along all the process. I'm still not sure this would work, but I've at least convinced myself that on a pax kernel with everything compiled PIC, vdso is mapped to a random address upon load/link, but it remains fixed during the life of the process and is the same for all threads, as you would expect. I'll attach a little poc you can play with. You might also want to look at http://articles.manugarg.com/systemcallinlinux2_6.html for how sysentry works via __kernel_vsyscall in vdso.
Created attachment 389152 [details] where does vdso live for a three threaded process
(In reply to Francisco Blas Izquierdo Riera from comment #17) TLS variables tend to be faster than global variables, and that is the sort of thing you want for syscalls. looking up the value via TLS is a single insn (the register + constant offset) and can be integrated directly into the call (vs indirect jump). using a global variable means going through the GOT. TLS data is also largely guaranteed to be local to the active cpu since it, by definition, can only be accessed by the current thread. conversely, the global variable will be in the shared data page with other variables that will bounce between threads and most likely between caches (since it can easily end up next to a writable variable, and memory is shared in cache line increments). the current patch, while annoying to carry at all, isn't terribly onerous to maintain. it would be good if we could convince upstream to merge something like it, but i guess we don't have precedence in this case with other arches that have funky bootstrap logic.
Created attachment 389536 [details] benchmarking For the records, here's a program to benchmark syscalls via int 0x80 vs vsyscall. Here's what I got on my system: time-int80 = 11.767331 time-vsyscall = 7.781346 time-got = 7.769142 time-libc = 0.383092 pid_int80 = 13906, pid_vsyscal = 13906, pid_got = 13906, pid_libc = 13906 Storing the vsyscall address in the GOT does seem slightly faster.
My tests returned similar results but with higher variability so a few times the non got method was faster.(In reply to SpanKY from comment #26) > (In reply to Francisco Blas Izquierdo Riera from comment #17) > > TLS variables tend to be faster than global variables, and that is the sort > of thing you want for syscalls. looking up the value via TLS is a single > insn (the register + constant offset) and can be integrated directly into > the call (vs indirect jump). using a global variable means going through > the GOT. TLS data is also largely guaranteed to be local to the active cpu > since it, by definition, can only be accessed by the current thread. > conversely, the global variable will be in the shared data page with other > variables that will bounce between threads and most likely between caches > (since it can easily end up next to a writable variable, and memory is > shared in cache line increments). > > the current patch, while annoying to carry at all, isn't terribly onerous to > maintain. it would be good if we could convince upstream to merge something > like it, but i guess we don't have precedence in this case with other arches > that have funky bootstrap logic. If we preload the value in the PLT on the linker then writability should stop being a problem. I have also realized that the SSP canary ends up in the TLS too. Why it still isn't causing crashes I don't know.
(In reply to Anthony Basile from comment #27) but you're benchmarking a single process, not a threaded process, which is the point of using TLS ;). also, GOT lookup requires %ebx all the time which causes register pressure where as %gs is always available and set to the right thing. you don't want to benchmark getpid() because glibc caches that internally. pick a different impotent call like close(-1). that's why your timing information for the last one is so fast.
(In reply to SpanKY from comment #29) > (In reply to Anthony Basile from comment #27) > > but you're benchmarking a single process, not a threaded process, which is > the point of using TLS ;). also, GOT lookup requires %ebx all the time > which causes register pressure where as %gs is always available and set to > the right thing. I did try threaded as well and didn't get much different. I'll play with it a bit more and post the results. > > you don't want to benchmark getpid() because glibc caches that internally. > pick a different impotent call like close(-1). that's why your timing > information for the last one is so fast. I figured that when i saw the results :)
