$ uname -r 2.6.35-hardened-r3 # valgrind ==18949== ==18949== Valgrind's memory management: out of memory: ==18949== newSuperblock's request for 4194304 bytes failed. ==18949== 8282112 bytes have already been allocated. ==18949== Valgrind cannot continue. Sorry. ==18949== ==18949== There are several possible reasons for this. ==18949== - You have some kind of memory limit in place. Look at the ==18949== output of 'ulimit -a'. Is there a limit on the size of ==18949== virtual memory or address space? ==18949== - You have run out of swap space. ==18949== - Valgrind has a bug. If you think this is the case or you are ==18949== not sure, please let us know and we'll try to fix it. ==18949== Please note that programs can take substantially more memory than ==18949== normal when running under Valgrind tools, eg. up to twice or ==18949== more, depending on the tool. On a 64-bit machine, Valgrind ==18949== should be able to make use of up 32GB memory. On a 32-bit ==18949== machine, Valgrind should be able to use all the memory available ==18949== to a single process, up to 4GB if that's how you have your ==18949== kernel configured. Most 32-bit Linux setups allow a maximum of ==18949== 3GB per process. ==18949== ==18949== Whatever the reason, Valgrind cannot continue. Sorry. End of strace: execve("/usr/lib/valgrind/memcheck-x86-linux", ["valgrind"], [/* 30 vars */]) = 0 open("/proc/self/maps", O_RDONLY) = 3 read(3, "38000000-381d9000 r-xp 00000000 "..., 100000) = 341 read(3, "", 99659) = 0 close(3) = 0 mmap2(0x5b36c000, 4194304, PROT_READ|PROT_WRITE|PROT_EXEC, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, 0, 0) = -1 EPERM (Operation not permitted) getpid() = 18969 write(2, "==18969== \n==18969== Valgrin"..., 521==18969== ==18969== Valgrind's memory management: out of memory: [...] Reproducible: Always emerge --info Portage 2.1.8.3 (hardened/linux/x86/10.0, gcc-4.4.5, glibc-2.11.2-r0, 2.6.35-hardened-r3 i686) ================================================================= System uname: Linux-2.6.35-hardened-r3-i686-Pentium-R-_Dual-Core_CPU_E6300_@_2.80GHz-with-gentoo-1.12.13 Timestamp of tree: Mon, 18 Oct 2010 06:45:01 +0000 ccache version 2.4 [enabled] app-shells/bash: 4.1_p7 dev-lang/python: 2.6.5-r3, 3.1.2-r4 dev-util/ccache: 2.4-r7 dev-util/cmake: 2.8.1-r2 sys-apps/baselayout: 1.12.13 sys-apps/sandbox: 2.3-r1 sys-devel/autoconf: 2.65-r1 sys-devel/automake: 1.10.3, 1.11.1 sys-devel/binutils: 2.20.1-r1 sys-devel/gcc: 4.4.5 sys-devel/gcc-config: 1.4.1 sys-devel/libtool: 2.2.10 sys-devel/make: 3.81-r2 virtual/os-headers: 2.6.30-r1 ACCEPT_KEYWORDS="x86" ACCEPT_LICENSE="* -@EULA" CBUILD="i686-pc-linux-gnu" CFLAGS="-O0 -march=native -mfpmath=sse -g -pipe" CHOST="i686-pc-linux-gnu" CONFIG_PROTECT="/etc /var/bind" CONFIG_PROTECT_MASK="/etc/ca-certificates.conf /etc/env.d /etc/eselect/postgresql /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" CXXFLAGS="-O0 -march=native -mfpmath=sse -g -pipe" DISTDIR="/usr/portage/distfiles" FEATURES="XXnoclean XXnostrip assume-digests ccache collision-protect distlocks fixpackages news parallel-fetch protect-owned sandbox sfperms strict unmerge-logs unmerge-orphans userfetch" GENTOO_MIRRORS="http://trumpetti.atm.tut.fi/gentoo/" LANG="pl" LC_ALL="pl_PL.utf-8" LDFLAGS="-Wl,-O1 -Wl,--as-needed" LINGUAS="pl" MAKEOPTS="-j1" PKGDIR="/usr/portage/packages" PORTAGE_CONFIGROOT="/" PORTAGE_RSYNC_EXTRA_OPTS="-6 -y" 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/portage/local/layman/sunrise /usr/portage/local/layman/gnustep /usr/portage/local/layman/steev /usr/portage/local/layman/sping /usr/portage/local /usr/local/portage/miro/staging /usr/local/portage/miro/portage" SYNC="rsync://trumpetti.atm.tut.fi/gentoo-portage/" USE="acl acpi adns aio apache2 ares bash-completion bcmath bzip2 caps chroot clamav clamdtop cli cracklib crypt curl custom-cflags cxx dkim dri dsn enscript exiscan exiscan-acl fam fastcgi force-cgi-redirect gnutls graphite hardened iconv idn imap iproute2 ipv6 logrotate lzo maildir mmap mmx modules mudflap ncurses network-cron nls nptl nptlonly objc objc++ objc-gc openmp openssl pam pcre perl pic pppd profiling python readline reflection sctp server session sharedmem slang spell srs sse sse2 sse3 ssl ssse3 subversion suhosin sysfs syslog threads threadsafe tools unicode urandom vhosts vim vim-pager vim-syntax x86 xattr xml xorg zip zlib" 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 auth_digest authn_dbm authn_default authn_file authz_dbm authz_default authz_groupfile authz_host authz_owner authz_user cache cgid dav dav_fs dav_lock dir disk_cache env expires ext_filter file_cache filter headers include info log_config logio mem_cache mime mime_magic negotiation rewrite setenvif status unique_id usertrack vhost_alias" APACHE2_MPMS="prefork" 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 ubx" INPUT_DEVICES="keyboard mouse evdev" KERNEL="linux" LCD_DEVICES="bayrad cfontz cfontz633 glk hd44780 lb216 lcdm001 mtxorb ncurses text" LINGUAS="pl" NGINX_MODULES_HTTP="access auth_basic browser charset fastcgi gzip limit_req limit_zone map proxy referer rewrite stub_status upstream_ip_hash userid" PHP_TARGETS="php-5.2" RUBY_TARGETS="ruby18" USERLAND="GNU" VIDEO_CARDS="apm ark chips cirrus cyrix dummy fbdev glint i128 i740 intel mach64 mga neomagic nsc nv r128 radeon rendition s3 s3virge savage siliconmotion sis sisusb tdfx tga trident tseng v4l vesa via vmware voodoo" XTABLES_ADDONS="geoip ipset psd tarpit" Unset: CPPFLAGS, CTARGET, EMERGE_DEFAULT_OPTS, FFLAGS, INSTALL_MASK, PORTAGE_COMPRESS, PORTAGE_COMPRESS_FLAGS
I can confirm this too. x86, 2.6.34-hardened-r5.
(In reply to comment #0) > mmap2(0x5b36c000, 4194304, PROT_READ|PROT_WRITE|PROT_EXEC, > MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, 0, 0) = -1 EPERM (Operation not permitted) Hardened kernels generally dislike granting RWX mappings. As far as I know, your options are: (1) Disable the security feature that blocks WX mappings. This is not recommended. (2) Do not request a WX mapping. This might cause a segmentation fault later if Valgrind actually does write code to the mapping and then execute that code. (3) Use paxctl to adjust the ELF header so that the specific application is exempt from the security feature that blocks WX mappings. I believe disabling the PaX MPROTECT feature is sufficient to let Valgrind run.
(In reply to comment #2) > I believe disabling > the PaX MPROTECT feature is sufficient to let Valgrind run. Unluckily, disabling MPROTECT isn't sufficient: # paxctl -v /usr/bin/valgrind PaX control v0.5 Copyright 2004,2005,2006,2007 PaX Team <pageexec@freemail.hu> - PaX flags: -p-s-m-x-e-r [/usr/bin/valgrind] PAGEEXEC is disabled SEGMEXEC is disabled MPROTECT is disabled RANDEXEC is disabled EMUTRAMP is disabled RANDMMAP is disabled $ valgrind ==12933== ==12933== Valgrind's memory management: out of memory: ==12933== newSuperblock's request for 4194304 bytes failed. ==12933== 8253440 bytes have already been allocated. ==12933== Valgrind cannot continue. Sorry.
This sounds like bug #329499 all over again. The restrictions in grsec-2.2.0 are preventing this mmaping. I suspect that if the reporter tries hardened-sources-2.6.32-r9 the problem will not manifest itself because that kernel is based on grsec-2.1.14 which did not forbid mmapings with PROT_READ|PROT_WRITE|PROT_EXEC. It is unclear whether valgrind can do its job without WX. We can try removing the W permissions and seeing.
valgrind generates code at runtime so MPROTECT must be disabled on its binaries (paxctl -m /usr/lib/valgrind/*). i don't know why the ebuild doesn't do it, i thought we'd fixed this years ago. about comment #3, can you strace your paxctl'd binary again? also check that your kernel config enables the use of PT_PAX_FLAGS.
# zgrep "PT_PAX_FLAGS" /proc/config.gz CONFIG_PAX_PT_PAX_FLAGS=y > (paxctl -m /usr/lib/valgrind/*). This (and paxctl -m /usr/bin/valgrind) solved problem. Is strace log still needed?
(In reply to comment #6) > > (paxctl -m /usr/lib/valgrind/*). > This (and paxctl -m /usr/bin/valgrind) solved problem. > Is strace log still needed? no, it isn't, i just thought that you had the problem with all binaries paxctl't but apparently that wasn't the case ;). so the solution is to change the ebuild to exempt these binaries from MPROTECT.
(In reply to comment #7) > so the solution is to change the ebuild to exempt these binaries from MPROTECT. Maintainer(s): recent versions of www-client/firefox exempt one of its installed files. Hopefully, this is useful as a reference: $ grep -n pax /usr/portage/www-client/firefox/firefox-3.6.9-r1.ebuild 7:inherit flag-o-matic toolchain-funcs eutils mozconfig-3 makeedit multilib pax-utils fdo-mime autotools mozextension java-pkg-opt-2 python 259: pax-mark m "${ED}"/${MOZILLA_FIVE_HOME}/firefox Looking at /usr/portage/eclass/pax-utils.eclass, the use of the helper function pax-mark (called from src_install) seems to be preferred over directly calling paxctl. The helper is somewhat clever in the ways it tries to insert the flags and it will automatically print a warning about any files that it was unable to mark, so users will at least be advised of potential problems if they install Valgrind without having paxctl (or its alternatives) available.
Currently valgrind is not maintained. At some point I'll add the pax-mark m to the ebuild.
Here are the changes to the ebuild. I'll put up valgrind-3.5.0-r1 in about a week when people have had time to review this. --- /usr/portage/dev-util/valgrind/valgrind-3.5.0.ebuild 2010-08-19 14:05:53.000000000 -0400 +++ valgrind-3.5.0-r1.ebuild 2010-10-27 17:18:25.000000000 -0400 @@ -2,7 +2,7 @@ # Distributed under the terms of the GNU General Public License v2 # $Header: /var/cvsroot/gentoo-x86/dev-util/valgrind/valgrind-3.5.0.ebuild,v 1.9 2010/08/19 17:58:17 ssuominen Exp $ -inherit autotools eutils flag-o-matic toolchain-funcs +inherit autotools eutils flag-o-matic toolchain-funcs multilib pax-utils DESCRIPTION="An open-source memory debugger for GNU/Linux" HOMEPAGE="http://www.valgrind.org" @@ -10,7 +10,7 @@ LICENSE="GPL-2" SLOT="0" -KEYWORDS="-* amd64 ppc ppc64 x86 ~amd64-linux ~x86-linux" +KEYWORDS="-* ~amd64 ~ppc ~ppc64 ~x86 ~amd64-linux ~x86-linux" IUSE="mpi" DEPEND="mpi? ( virtual/mpi )" @@ -94,6 +94,11 @@ src_install() { emake DESTDIR="${D}" install || die "Install failed!" dodoc AUTHORS FAQ.txt NEWS README* + + local LIB=$(get_libdir) + + pax-mark m "${D}"/usr/bin/* + pax-mark m "${D}"/usr/"${LIB}"/valgrind/* } pkg_postinst() {
(In reply to comment #10) > Here are the changes to the ebuild. I'll put up valgrind-3.5.0-r1 in about a > week when people have had time to review this. > > --- /usr/portage/dev-util/valgrind/valgrind-3.5.0.ebuild 2010-08-19 > 14:05:53.000000000 -0400 > +++ valgrind-3.5.0-r1.ebuild 2010-10-27 17:18:25.000000000 -0400 > @@ -94,6 +94,11 @@ > + > + local LIB=$(get_libdir) > + > + pax-mark m "${D}"/usr/bin/* > + pax-mark m "${D}"/usr/"${LIB}"/valgrind/* That looks like overkill. Valgrind ships various helper tools that do not need MPROTECT relaxed, so marking everything is unnecessary. We know that /usr/lib/valgrind/memcheck-x86-linux is affected (comment #0), and it is very likely that memcheck-amd64-linux needs to be marked. A quick check shows that all of the *-amd64-linux binaries need to be marked: (cd /usr/lib64/valgrind/ ; for a in *-amd64-linux; do echo ${a/-amd64-linux}; done) | while read t; do strace -o $t.txt -e trace=mmap,execve valgrind --tool=$t /bin/true 2>/dev/null ; done grep -l mmap'.*PROT_WRITE.*PROT_EXEC' *.txt |wc Based on that, a better choice for pax-mark is probably to do /usr/$(get_libdir)/valgrind/*-*-linux, but leave alone all of the binaries in /usr/bin and leave alone the supporting ELF files in /usr/lib/valgrind.
(In reply to comment #11) > (In reply to comment #10) > > Here are the changes to the ebuild. I'll put up valgrind-3.5.0-r1 in about a > > week when people have had time to review this. > > > > --- /usr/portage/dev-util/valgrind/valgrind-3.5.0.ebuild 2010-08-19 > > 14:05:53.000000000 -0400 > > +++ valgrind-3.5.0-r1.ebuild 2010-10-27 17:18:25.000000000 -0400 > > @@ -94,6 +94,11 @@ > > + > > + local LIB=$(get_libdir) > > + > > + pax-mark m "${D}"/usr/bin/* > > + pax-mark m "${D}"/usr/"${LIB}"/valgrind/* > > That looks like overkill. Valgrind ships various helper tools that do not need > MPROTECT relaxed, so marking everything is unnecessary. We know that > /usr/lib/valgrind/memcheck-x86-linux is affected (comment #0), and it is very > likely that memcheck-amd64-linux needs to be marked. A quick check shows that > all of the *-amd64-linux binaries need to be marked: > > (cd /usr/lib64/valgrind/ ; for a in *-amd64-linux; do echo ${a/-amd64-linux}; > done) | while read t; do strace -o $t.txt -e trace=mmap,execve valgrind > --tool=$t /bin/true 2>/dev/null ; done > grep -l mmap'.*PROT_WRITE.*PROT_EXEC' *.txt |wc > > Based on that, a better choice for pax-mark is probably to do > /usr/$(get_libdir)/valgrind/*-*-linux, but leave alone all of the binaries in > /usr/bin and leave alone the supporting ELF files in /usr/lib/valgrind. > Yes, total overkill. Thanks. The problem appears only due to PROT_WRITE, PROT_EXEC mmappings and only in /usr/$(get_libdir)/valgrind/*-*-linux. So I was able to reduce the pax markings to just pax-mark m "${D}"/usr/$(get_libdir)/valgrind/*-*-linux It'll go into the tree that way.
Okay its in the tree as valgrind-3.5.0-r1.ebuild. I'll close this fixed. Please test and reopen if there is a problem.
Works for me, thank you for fixing and taking care for package.
