Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 240956 - >=media-libs/mesa-7.2 causes a problem with pax mprotect
Summary: >=media-libs/mesa-7.2 causes a problem with pax mprotect
Status: RESOLVED FIXED
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: Hardened (show other bugs)
Hardware: x86 Linux
: High major (vote)
Assignee: The Gentoo Linux Hardened Team
URL:
Whiteboard:
Keywords: Inclusion
: 244661 263879 306707 354239 355469 357179 357245 (view as bug list)
Depends on:
Blocks:
 
Reported: 2008-10-10 02:40 UTC by James Browning
Modified: 2012-08-23 13:53 UTC (History)
12 users (show)

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


Attachments
Add an option "--enable-glx-rts" to mesa's configure script (mesa_glx_ro_text_segm.diff,540 bytes, text/plain)
2008-11-18 00:40 UTC, Hugo Mildenberger
Details
New Gentoo ebuild packed together with the --enable-glx-rts patch (mesa-7.2-r1.ebuild.tar.gz,3.67 KB, application/octet-stream)
2008-11-18 17:45 UTC, Hugo Mildenberger
Details
7.2-glx_ro_text_segm.patch (7.2-glx_ro_text_segm.patch,598 bytes, patch)
2009-02-20 00:53 UTC, Jeremy Huddleston Sequoia
Details | Diff
mesa-7.2-r1.patch (mesa-7.2-r1.patch,1.32 KB, patch)
2009-02-20 00:53 UTC, Jeremy Huddleston Sequoia
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description James Browning 2008-10-10 02:40:46 UTC
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
Comment 1 Hugo Mildenberger 2008-11-16 01:27:36 UTC
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:
Comment 2 Hugo Mildenberger 2008-11-16 02:55:01 UTC
(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)
Comment 3 Hugo Mildenberger 2008-11-18 00:17:20 UTC
(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.
Comment 4 Hugo Mildenberger 2008-11-18 00:40:11 UTC
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.
Comment 5 Hugo Mildenberger 2008-11-18 14:10:42 UTC
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.
Comment 6 Hugo Mildenberger 2008-11-18 17:45:53 UTC
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.
Comment 7 Jeremy Huddleston Sequoia 2009-02-20 00:40:59 UTC
Please post ebuilds as plain text rather than tarballs...
Comment 8 Jeremy Huddleston Sequoia 2009-02-20 00:53:09 UTC
Created attachment 182595 [details, diff]
7.2-glx_ro_text_segm.patch
Comment 9 Jeremy Huddleston Sequoia 2009-02-20 00:53:45 UTC
Created attachment 182597 [details, diff]
mesa-7.2-r1.patch

diff between mesa-7.2.ebuild and the new mesa-7.2-r1.ebuild
Comment 10 Jeremy Huddleston Sequoia 2009-02-20 01:01:39 UTC
I cleaned up the ebuild submitted by Hugo.  Please integrate this.  Tested with Intel DRI
Comment 11 Hugo Mildenberger 2009-04-12 13:04:17 UTC
(In reply to comment #10)
Sad to see that the very same problem still persists in mesa-7.4.ebuild, about two month later. 
Comment 12 Jeremy Huddleston Sequoia 2009-04-12 21:27:38 UTC
This is trivial, and I have attached a clean patch to the source and ebuild.  Please commit.
Comment 13 Rémi Cardona gentoo-dev 2009-04-19 16:57:57 UTC
Ack for 7.2. @Hardened, feel free to commit.

@Jeremy, what about 7.4 and newer?

Thanks
Comment 14 Jeremy Huddleston Sequoia 2009-04-19 19:59:50 UTC
The same needs to be done for 7.4.  I believe the 7.2 patches will apply cleanly to 7.4 as well.
Comment 15 Hugo Mildenberger 2009-04-20 11:46:35 UTC
(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.
Comment 16 Rémi Cardona gentoo-dev 2009-04-27 12:18:10 UTC
@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
Comment 17 Radoslaw Madej (radegand) 2009-07-11 18:21:51 UTC
(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!
Comment 18 Tomáš Chvátal (RETIRED) gentoo-dev 2009-08-21 07:54:43 UTC
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 :]
Comment 19 Tomáš Chvátal (RETIRED) gentoo-dev 2009-08-27 09:05:38 UTC
*** Bug 244661 has been marked as a duplicate of this bug. ***
Comment 20 Tomáš Chvátal (RETIRED) gentoo-dev 2009-08-27 09:06:57 UTC
*** Bug 263879 has been marked as a duplicate of this bug. ***
Comment 21 Xake 2010-02-18 05:26:35 UTC
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?
Comment 22 Jeremy Huddleston Sequoia 2010-02-18 07:51:20 UTC
This issues is still relevant through 7.7... as is the fix.
Comment 23 Xake 2010-02-18 08:11:00 UTC
(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?
Comment 24 Samuli Suominen gentoo-dev 2010-02-24 19:48:31 UTC
*** Bug 306707 has been marked as a duplicate of this bug. ***
Comment 25 Xake 2010-04-21 20:17:44 UTC
@scarabeus:

I have no time to send this patch upstream, do you think you can do it?
Comment 26 Tomáš Chvátal (RETIRED) gentoo-dev 2010-04-21 20:35:49 UTC
I actualy sent it to mesa-dev ml.
1.12.2009...

http://marc.info/?l=mesa3d-dev&m=125970571528105&w=3
Comment 27 Hugo Mildenberger 2010-08-03 19:05:45 UTC
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.
Comment 28 Magnus Granberg gentoo-dev 2010-08-04 00:43:11 UTC
* 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"
Comment 29 Magnus Granberg gentoo-dev 2010-08-04 03:21:15 UTC
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?

 
Comment 30 Magnus Granberg gentoo-dev 2010-08-04 16:11:10 UTC
http://marc.info/?l=mesa3d-dev&m=128093795712342&w=3
Ping on the patch.
Comment 31 Magnus Granberg gentoo-dev 2010-08-04 21:17:36 UTC
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?
Comment 32 Magnus Granberg gentoo-dev 2010-08-04 21:18:12 UTC
(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.
Comment 33 Hugo Mildenberger 2010-08-06 14:03:14 UTC
(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*"



Comment 34 Hugo Mildenberger 2010-10-16 18:04:36 UTC
ping hardened@gentoo.org ... 
Comment 35 Magnus Granberg gentoo-dev 2010-11-10 21:36:39 UTC
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

Comment 36 Fernando (likewhoa) 2011-02-09 15:43:18 UTC
*** Bug 354239 has been marked as a duplicate of this bug. ***
Comment 37 Fernando (likewhoa) 2011-02-09 16:32:01 UTC
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"
Comment 38 Francisco Blas Izquierdo Riera gentoo-dev 2011-02-09 17:11:43 UTC
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.
Comment 39 Hugo Mildenberger 2011-02-09 17:26:31 UTC
(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?)  
Comment 40 Francisco Blas Izquierdo Riera gentoo-dev 2011-02-09 18:06:08 UTC
(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.
Comment 41 Fernando (likewhoa) 2011-02-09 18:14:38 UTC
(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.
Comment 42 Fernando (likewhoa) 2011-02-09 18:28:27 UTC
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.
Comment 43 Xake 2011-02-09 19:35:57 UTC
(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.
Comment 44 Fernando (likewhoa) 2011-02-09 21:06:41 UTC
(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.
Comment 45 Magnus Granberg gentoo-dev 2011-02-09 22:29:11 UTC
Fixed in mesa-7.10-r1
Comment 46 Magnus Granberg gentoo-dev 2011-02-09 22:59:48 UTC
Have reping the mesa-dev lm with this fix.
Comment 47 Pacho Ramos gentoo-dev 2011-02-18 21:12:31 UTC
*** Bug 355469 has been marked as a duplicate of this bug. ***
Comment 48 Chí-Thanh Christopher Nguyễn gentoo-dev 2011-03-03 19:24:05 UTC
*** Bug 357179 has been marked as a duplicate of this bug. ***
Comment 49 Jeroen Roovers gentoo-dev 2011-03-04 00:41:18 UTC
*** Bug 357245 has been marked as a duplicate of this bug. ***
Comment 50 wbrana 2012-08-23 10:31:17 UTC
Is pic flag still needed?
Comment 51 Magnus Granberg gentoo-dev 2012-08-23 13:53:32 UTC
(In reply to comment #50)
> Is pic flag still needed?

yes on x86