the latest unstable mesa causes dependant binaries to exhibit mprotect errors unless they are treated w/ 'paxctl -m'. stderr spits out '/usr/lib/xulrunner/xulrunner-bin: error while loading shared libraries: //usr//lib/opengl/xorg-x11/lib/libGL.so.1: cannot make segment writable for relocation: Permission denied' when running xulrunner. This also affects xchat and gnumeric. flagging the /usr//lib/opengl/xorg-x11/lib/libGL.so.1 is insufficient to enable binaries to run. Reproducible: Always Steps to Reproduce: 1. Install libGL dependant apps and mesa 7.2 on a hardened system with paxs mprotect 2. attempt to execute libGL dependant app from a xterm Actual Results: App dies outputting something similar to the following to stderr: /usr/lib/xulrunner/xulrunner-bin: error while loading shared libraries: //usr//lib/opengl/xorg-x11/lib/libGL.so.1: cannot make segment writable for relocation: Permission denied Expected Results: The app should run normally. Portage 2.2_rc11 (selinux/2007.0/x86/hardened, gcc-4.2.4, glibc-2.8_p20080602-r0, 2.6.26-hardened-r2 i686) ================================================================= System uname: Linux-2.6.26-hardened-r2-i686-Intel-R-_Celeron-R-_CPU_2.66GHz-with-glibc2.4 Timestamp of tree: Sat, 04 Oct 2008 10:45:01 +0000 app-shells/bash: 3.2_p33 dev-java/java-config: 1.3.7, 2.1.6 dev-lang/python: 2.4.4-r15, 2.5.2-r8 dev-python/pycrypto: 2.0.1-r6 sys-apps/baselayout: 2.0.0 sys-apps/openrc: 9999 sys-apps/sandbox: 1.2.18.1-r2 sys-devel/autoconf: 2.13, 2.61-r2 sys-devel/automake: 1.4_p6, 1.5, 1.6.3, 1.7.9-r1, 1.8.5-r3, 1.9.6-r2, 1.10.1-r1 sys-devel/binutils: 2.18-r4 sys-devel/gcc-config: 1.4.0-r4 sys-devel/libtool: 1.5.26 virtual/os-headers: 2.6.23-r3 ACCEPT_KEYWORDS="x86" CBUILD="i686-pc-linux-gnu" CFLAGS="-march=pentium2 -mtune=prescott -O2 -pipe -g -ggdb" CHOST="i686-pc-linux-gnu" CONFIG_PROTECT="/etc /usr/kde/3.5/env /usr/kde/3.5/share/config /usr/kde/3.5/shutdown /usr/kde/4.1/env /usr/kde/4.1/share/config /usr/kde/4.1/shutdown /usr/share/config /var/lib/hsqldb" CONFIG_PROTECT_MASK="/etc/ca-certificates.conf /etc/env.d /etc/env.d/java/ /etc/fonts/fonts.conf /etc/gconf /etc/gentoo-release /etc/revdep-rebuild /etc/terminfo /etc/texmf/web2c /etc/udev/rules.d" CXXFLAGS="-march=pentium2 -mtune=prescott -O2 -pipe -g -ggdb" DISTDIR="/usr/portage/distfiles" FEATURES="candy ccache distlocks loadpolicy metadata-transfer nostrip parallel-fetch preserve-libs protect-owned sandbox selinux sesandbox severe sfperms splitdebug strict unmerge-orphans userfetch userpriv usersandbox" GENTOO_MIRRORS="http://gentoo.osuosl.org/ http://mirror.usu.edu/mirrors/gentoo/ ftp://ftp.wwc.edu/pub/mirrors/ftp.gentoo.org " LANG="en_US" LC_ALL="en_US" LDFLAGS="" PKGDIR="/usr/portage/packages" 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="/home/overlays/openrc /home/overlays/gnustep /home/overlays/sunrise /home/overlays/toolchain /home/overlays/upstart /home/overlays/jamesb" SYNC="rsync://rsync.namerica.gentoo.org/gentoo-portage" USE="X a52 aac acl acpi alsa arts artworkextra avahi berkdb branding bzip2 cddb cdr cdrom cgi cli cracklib crypt cups curl dbus debug debug-freelist debug-malloc debugger dga dmi doc double-precision dri dvd dvdr dvdread dvi eds examples exif exiv2 fam ffmpeg flac fortran freeimage fuse gcc64 gcj gdbm gif glibc-compat20 glitz gnome gnome-print gnomecanvas gnomedb gnustep gnutls gpm gtk gtk2 gtkhtml gtkspell hal hardened iconv ipv6 isdnlog java javascript jpeg jpeg2k kdrive kerberos lcms ldap logrotate mad midi mikmod mmx motif mp3 mp4 mpeg mpeg2 msn msnextras mudflap nautilus ncurses net nls nntp nptl nptlonly numeric objhc offensive ogg opengl openmp openssl oscar pam pam_chroot pam_timestamp pango paste64 patch pcre pda pdf perl pic pmu png pppd python qt3 qt3support qt4 quicktime quotas rdesktop readline real reflection rogue sdl selinux session slp spell spl sse sse2 ssl svg sysfs t1lib tcl tcpd test theora threads threadsafe threadsonly tiff tk truetype truetype-fonts unharden unicode usb utempter v4l v4l2 vorbis win32codecs winpopup x86 xattr xcomposite xinerama xorg yahoo 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 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 void evdev" KERNEL="linux" LCD_DEVICES="bayrad cfontz cfontz633 glk hd44780 lb216 lcdm001 mtxorb ncurses text" USERLAND="GNU" VIDEO_CARDS="dummy fbdev i810 v4l vesa vga" Unset: CPPFLAGS, CTARGET, EMERGE_DEFAULT_OPTS, FFLAGS, INSTALL_MASK, LINGUAS, MAKEOPTS, PORTAGE_COMPRESS, PORTAGE_COMPRESS_FLAGS, PORTAGE_RSYNC_EXTRA_OPTS
Same here, on ~x86 with gcc-4.2.4 from xake-toolchain; obviously due to an executable stack in mesa. However, not all OpenGL applications are affected. But glxgears is, as is glxinfo. emerge mesa says: QA Notice: The following files contain executable stacks --- R-X RWX usr/lib/opengl/xorg-x11/lib/libGL.so.1.2 dmesg says: PAX: execution attempt in: /usr/lib/opengl/xorg-x11/lib/libGL.so.1.2, 552ca000-552ce000 00067000 PAX: terminating task: /usr/bin/glxgears(glxgears):3229, uid/euid: 1000/1000, PC: 552cb960, SP: 5f70b67c PAX: bytes at PC: 65 a1 f8 ff ff ff ff a0 80 02 00 00 8d 74 26 00 65 a1 f8 ff PAX: bytes at SP-4:
(In reply to my own comment #1) gdb-6.8 is unable to track the problem directly. But "ulimit -c unlimited" enables core dumps. Then "gdb --core=./core /usr/bin/glxinfo" says this: Core was generated by `glxinfo'. Program terminated with signal 9, Killed. [New process 4421] #0 glGetString () at ../src/mesa/x86/glapi_x86.S:429 429 ../src/mesa/x86/glapi_x86.S: No such file or directory. in ../src/mesa/x86/glapi_x86.S (gdb) bt #0 glGetString () at ../src/mesa/x86/glapi_x86.S:429 #1 0x11685126 in main (argc=1, argv=0x5c94a0d4) at glxinfo.c:471 (gdb) disass Dump of assembler code for function glGetString: 0x517da090 <glGetString+0>: mov %gs:0xfffffff8,%eax 0x517da096 <glGetString+6>: jmp *0x44c(%eax) 0x517da09c <glGetString+12>: lea 0x0(%esi,%eiz,1),%esi End of assembler dump. src/mesa/x86/glapi_x86.S +429 is: 429 GL_STUB(GetString, _gloffset_GetString, GetString@4)
(In continuation of comment #2) On x86, mesa already provides a solution for this problem. If the preprocessor symbol GLX_X86_READONLY_TEXT would be defined during configure, then the text segment of libGL would be completely readonly, and thus the pax related problem would have been gone - at least in theory. Practically, this works only for glxinfo (which didn't work before), but not for any other libGL-dependant program. All other opengl programs which I have tried had then constantantly been killed within mesa's choose_emit_func(), therein upon calling vtx->emit(), which for some reason became an invalid pointer. Thus the hithereto unused GLX_X86_READONLY_TEXT seems to expose a bug within mesa. But maybe the root of the new problem is still within src/mesa/x86/glapi_x86.S ? I will later post a patch against configure.ac (current git version), which introduces the configure option "--enable-glx-rts", which, if used, would add -DGLX_X86_READONLY_TEXT to the list of compilation flags. I would be interested to hear if this patch would fix the problem on other hardened systems, which are (to some varying extend) differently configured. I suppose it could also have to do with having use flags like "sse2" enabled here.
Created attachment 172159 [details] Add an option "--enable-glx-rts" to mesa's configure script This is a patch against current git version of configure.ac (as of 2008/11/17). It will lead to the definition of the "GLX_X86_READONLY_TEXT" preprocessor symbol, if later on the "--enable-glx-rts" option is passed to the configure script. Remember to run autogen.sh (or at least autoconf) to regenerate the configure script.
Problem solved. It was induced by some sort of glue logic within mesa-7.2.ebuild, dealing with the --disable-asm configure switch. That bug forced portage to pass "--disable-asm" followed by "--enable-asm" to mesa's configure script (at least within my particular environment) Fixing this, mesa compiled fine with --disable-asm and --enable-glx-rts, and all opengl programs do run without any problems (only the framerate is about 3% less, when compared with the assembly-enabled version and without readonly text segements). Hence, the additional problem I encountered above is hidden somewhere in mesa's x86 assembly code. And the problem in mesa-7.2.ebuild which triggered it, is this: #Deactivate assembly code for pic build myconf="${myconf} $(use_enable !pic asm)" #Sparc assembly code is not working myconf="${myconf} $(use_enable !sparc asm)" Since I was not compiling on sparc, --enable-asm was put behind the first --disable-asm option, reenabling it.
Created attachment 172268 [details] New Gentoo ebuild packed together with the --enable-glx-rts patch On hardened x86, this ebuild generally replaces nearby all mesa's assembly coded parts by high-level implementations, and thus eliminates the problem completely. Yet it would be interesting to know which assembly coded object file had introduced the problem with readonly text segments, as mesa's configure script could be easily tuned to use only certain assembly implementations.
Please post ebuilds as plain text rather than tarballs...
Created attachment 182595 [details, diff] 7.2-glx_ro_text_segm.patch
Created attachment 182597 [details, diff] mesa-7.2-r1.patch diff between mesa-7.2.ebuild and the new mesa-7.2-r1.ebuild
I cleaned up the ebuild submitted by Hugo. Please integrate this. Tested with Intel DRI
(In reply to comment #10) Sad to see that the very same problem still persists in mesa-7.4.ebuild, about two month later.
This is trivial, and I have attached a clean patch to the source and ebuild. Please commit.
Ack for 7.2. @Hardened, feel free to commit. @Jeremy, what about 7.4 and newer? Thanks
The same needs to be done for 7.4. I believe the 7.2 patches will apply cleanly to 7.4 as well.
(In reply to comment #14) > The same needs to be done for 7.4. I believe the 7.2 patches will apply > cleanly to 7.4 as well. They do apply cleanly to mesa-7.4.
@Jeremy, Could you get them accepted to mesa's git tree? That would help not loose the patch in the future. I'll try to get to this bug soon. Thanks
(In reply to comment #16) Hi, I can confirm that this patch followed by updated ebuild also works for the current stable mesa 7.4.4 on hardened and PAX enabled kernel. happy days! :) Would it be possible to merge it with upstream and updated the ebuild? Thanks!
Confirmed as working with current HEAD. Should be sent to dri-devel ML as per talk with MAD on #dri-devel. @remi: Could you do that? Simple mail describing why it is needed (comment #3) Also build.log: http://dev.gentoo.org/~scarabeus/mesa-9999.log I will get to the mail 1.9. then i can do it :]
*** Bug 244661 has been marked as a duplicate of this bug. ***
*** Bug 263879 has been marked as a duplicate of this bug. ***
As 7.2 and 7.4 has been removed from portage, is this still valid? Does 7.5, the oldes and latest stable mesa ebuild in the portage tree work?
This issues is still relevant through 7.7... as is the fix.
(In reply to comment #22) > This issues is still relevant through 7.7... as is the fix. > Then comes the next questions: is the fix in portage and has it ever been pushed upstream?
*** Bug 306707 has been marked as a duplicate of this bug. ***
@scarabeus: I have no time to send this patch upstream, do you think you can do it?
I actualy sent it to mesa-dev ml. 1.12.2009... http://marc.info/?l=mesa3d-dev&m=125970571528105&w=3
As of mesa-7.8.2, my patch had not yet been included by upstream. For some reason, mesa now works without, maybe also because the pie vs asm issue was fixed in the meantime.
* QA Notice: The following files contain writable and executable sections * Files with such sections will not work properly (or at all!) on some * architectures/operating systems. A bug should be filed at * http://bugs.gentoo.org/ to make sure the issue is fixed. * For more information, see http://hardened.gentoo.org/gnu-stack.xml * Please include the following list of files in your report: * Note: Bugs should be filed for the respective maintainers * of the package in question and not hardened@g.o. * --- R-X --- usr/lib/opengl/xorg-x11/lib/libGL.so.1.2 media-libs/mesa-7.8.2 USE="nptl xcb -debug (-gallium) -motif -pic (-selinux)" VIDEO_CARDS="intel mach64 mga r128 radeon savage sis tdfx via -none -nouveau -radeonhd -svga" If i build it with pic use flag i get no QA prob in libGL.so.1.2 but then it disable all asm code. Portage 2.1.8.3 (hardened/linux/x86/10.0, gcc-4.4.4, glibc-2.11.2-r0, 2.6.34-hardened-r1 i686) ================================================================= System uname: Linux-2.6.34-hardened-r1-i686-Intel-R-_Xeon-R-_CPU_E5420_@_2.50GHz-with-gentoo-2.0.1 Timestamp of tree: Sun, 25 Jul 2010 21:45:01 +0000 app-shells/bash: 4.1_p7 dev-lang/python: 2.6.5-r3 sys-apps/baselayout: 2.0.1 sys-apps/openrc: 0.6.1-r1 sys-apps/sandbox: 2.2 sys-devel/autoconf: 2.65-r1 sys-devel/automake: 1.11.1 sys-devel/binutils: 2.20.1-r1 sys-devel/gcc: 4.4.4-r1 sys-devel/gcc-config: 1.4.1 sys-devel/libtool: 2.2.10 virtual/os-headers: 2.6.34 ACCEPT_KEYWORDS="x86 ~x86" ACCEPT_LICENSE="*" CBUILD="i686-pc-linux-gnu" CFLAGS="-O2 -pipe -march=i686" CHOST="i686-pc-linux-gnu"
And looks like there is no QA problem with pic use flag off on the x86_64 target It looks like the patch was signed-off by one develper but it did't get futhere. Can we ping the tread on the mesa-dev ml and see way it did't get in?
http://marc.info/?l=mesa3d-dev&m=128093795712342&w=3 Ping on the patch.
Looks like it will be commited if no one pipes up with any objections upstream. Someone willing to test the fix and run with out the pie use flag on x86 and amd64 arch?
(In reply to comment #31) > Looks like it will be commited if no one pipes > up with any objections upstream. Someone willing to test the fix and run with > out the pie use flag on x86 and amd64 arch? > Sorry the pic use flag.
(In reply to comment #31) Runs on hardened X86, with --enable-asm and --enable-glx-rts, with doubled framerate compared to +pic and without the fix. BTW, I really loved to find this "fix" in mesa-7.8.2: # It is slow without texrels, if someone wants slow # mesa without texrels +pic use is worth shot QA_EXECSTACK="usr/lib*/opengl/xorg-x11/lib/libGL.so*" QA_WX_LOAD="usr/lib*/opengl/xorg-x11/lib/libGL.so*"
ping hardened@gentoo.org ...
Have made a new ping to the lm and hope some thing will happen. http://lists.freedesktop.org/archives/mesa-dev/2010-November/003936.html
*** Bug 354239 has been marked as a duplicate of this bug. ***
slight modification to the ebuild so it works inside a non-hardened chroot --- mesa-7.2-r1.ebuild 2008-11-18 12:00:02.000000000 -0500 +++ mesa-7.2-r1.ebuild.new 2011-02-09 11:28:58.979868001 -0500 @@ -154,7 +154,7 @@ myconf="${myconf} --disable-asm" fi - if ( use hardened && use x86 ) ; then + if ( use hardened || use x86 ) ; then # Make glx text segments readonly on hardened myconf="${myconf} --enable-glx-rts" elog "Mesa assembly code is currently generally disabled on hardened x86"
That makes no sense you are saying that if we have either the hardened or the x86 use flags we should enable this options. This bug does not affect architectures other than x86 on hardened profiles thus the &&. If by any reason you need this patch on a non x86 arch please tell us which. If you need this on a non hardened kernel please tell us which one you are using. Other than this, if you are not using the hardened profile on a chroot done with a hardened kernel its yourr responsability enabling the appropriate use flags and you shouldn't expect support from us.
(In reply to comment #38) > Other than this, if you are not using the hardened profile on a chroot done > with a hardened kernel its yourr responsability enabling the appropriate use > flags and you shouldn't expect support from us. Support ... this bug opened over two years ago ... so simply close it with wontfix (or was it wontsupport?)
(In reply to comment #39) > (In reply to comment #38) > > Other than this, if you are not using the hardened profile on a chroot done > > with a hardened kernel its yourr responsability enabling the appropriate use > > flags and you shouldn't expect support from us. > > Support ... this bug opened over two years ago ... so simply close it with > wontfix (or was it wontsupport?) My fault, comment #38 was a reply to comment #37 not the whole bug.
(In reply to comment #40) > (In reply to comment #39) > > (In reply to comment #38) > > > Other than this, if you are not using the hardened profile on a chroot done > > > with a hardened kernel its yourr responsability enabling the appropriate use > > > flags and you shouldn't expect support from us. > > > > Support ... this bug opened over two years ago ... so simply close it with > > wontfix (or was it wontsupport?) > My fault, comment #38 was a reply to comment #37 not the whole bug. > The hardened host is a headless host so it doesn't include mesa or any X related packages. The chroot is x86 non-hardened and it does include X related packages and the current patch looks for "hardened and x86" USE flags which only x86 is available on the chroot, so yes this patch is needed but only on x86 not amd64 or other arches. I appreciated if you toned down your attitude I don't appreciated it.
just to add the current if statement is wrong since it will apply configure option to non-hardened host but the thing is, the chroot is running inside a hardened host and inside the chroot is non-hardened, so we need to check the presence of hardened outside the chroot somehow otherwise the original ebuild won't work on non-hardened x86 who are working on a hardened host.
(In reply to comment #42) > just to add the current if statement is wrong since it will apply configure > option to non-hardened host but the thing is, the chroot is running inside a > hardened host and inside the chroot is non-hardened, I think you have a misconception here: Hardened kernel == Hardened host. No exception. chroot is a way to run a new _userland_ on a already present host. They do _not_ run a new host in another host (that is a virtual machine). And that was exactly what klondike meant with: (In reply to comment #38) > Other than this, if you are not using the hardened profile on a chroot done > with a hardened kernel its yourr responsability enabling the appropriate use > flags and you shouldn't expect support from us. > This is because we simple cannot support anything else then a hardened profile for anything running on a hardened kernel. Now the choice is still up to you if you want to run a non hardened chroot on a hardened kernel, but as klondike pointed out it is up to you to enable the correct useflags for the packages (which essentially means that you want to enable the pic-flag all over, and on certain packages like mesa enable the hardened use flag) and we cannot really support this. So in that case /etc/portage/packade.use is your friend. Personally I think what you really want is a hardened profile, but with a nopie or even nopienossp gcc-config in that chroot, because it will enable everything that makes the chroot work on a hardened kernel, and remove the "pie" part which is on x86 the speed penalties people usually do not want. And this is very far off topic for this bugreport, if you want help with stuff like this we have http://forums.gentoo.org or #gentoo-hardened@irc.freenode.org which is far more suitable to discuss how to get stuff to work on a hardened host, and people depending on time may even help with unspported things.
(In reply to comment #43) > (In reply to comment #42) > > just to add the current if statement is wrong since it will apply configure > > option to non-hardened host but the thing is, the chroot is running inside a > > hardened host and inside the chroot is non-hardened, > > I think you have a misconception here: > Hardened kernel == Hardened host. > No exception. > chroot is a way to run a new _userland_ on a already present host. They do > _not_ run a new host in another host (that is a virtual machine). > And that was exactly what klondike meant with: > > (In reply to comment #38) > > Other than this, if you are not using the hardened profile on a chroot done > > with a hardened kernel its yourr responsability enabling the appropriate use > > flags and you shouldn't expect support from us. > > > > This is because we simple cannot support anything else then a hardened profile > for anything running on a hardened kernel. > Now the choice is still up to you if you want to run a non hardened chroot on a > hardened kernel, but as klondike pointed out it is up to you to enable the > correct useflags for the packages (which essentially means that you want to > enable the pic-flag all over, and on certain packages like mesa enable the > hardened use flag) and we cannot really support this. So in that case > /etc/portage/packade.use is your friend. > > Personally I think what you really want is a hardened profile, but with a nopie > or even nopienossp gcc-config in that chroot, because it will enable everything > that makes the chroot work on a hardened kernel, and remove the "pie" part > which is on x86 the speed penalties people usually do not want. > > And this is very far off topic for this bugreport, if you want help with stuff > like this we have http://forums.gentoo.org or #gentoo-hardened@irc.freenode.org > which is far more suitable to discuss how to get stuff to work on a hardened > host, and people depending on time may even help with unspported things. > Thanks that explains it better. See you on IRC, I already discuss some of this topic with Zorry but he mentioned the pic USE flag on mesa with hinder 3d performance and this is needed since this *chroot* is a livecd.
Fixed in mesa-7.10-r1
Have reping the mesa-dev lm with this fix.
*** Bug 355469 has been marked as a duplicate of this bug. ***
*** Bug 357179 has been marked as a duplicate of this bug. ***
*** Bug 357245 has been marked as a duplicate of this bug. ***
Is pic flag still needed?
(In reply to comment #50) > Is pic flag still needed? yes on x86
