Bug 178262 - /usr/lib/libGL.so.1.2 requests an executable stack
/usr/lib/libGL.so.1.2 requests an executable stack
Status: CLOSED RAWHIDE
Product: Fedora
Classification: Fedora
Component: mesa (Show other bugs)
rawhide
i686 Linux
medium Severity medium
: ---
: ---
Assigned To: Adam Jackson
X/OpenGL Maintenance List
:
: 182380 191191 (view as bug list)
Depends On:
Blocks: FC6Target FC5Update
  Show dependency treegraph
 
Reported: 2006-01-18 17:10 EST by Russell Coker
Modified: 2007-11-30 17:11 EST (History)
8 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2006-06-27 14:07:35 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Russell Coker 2006-01-18 17:10:47 EST
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (compatible; Konqueror/3.5; Linux) KHTML/3.5.0 (like Gecko)

Description of problem:
# readelf -l /usr/lib/libGL.so.1.2 |grep STACK 
  GNU_STACK      0x000000 0x00000000 0x00000000 0x00000 0x00000 RWE 0x4 
 
Let me know if it REALLY needs the executable stack and we can change SE Linux 
policy accordingly. 

Version-Release number of selected component (if applicable):


How reproducible:
Always

Steps to Reproduce:
1.
2.
3.
  

Additional info:
Comment 1 Mike A. Harris 2006-01-20 10:13:47 EST
libGL dlopen()s the individual DRI drivers, which in turn runtime allocate
memory which gets used for runtime code generation, so the memory must be
marked executable in order to function correctly.  In previous versions of
Mesa, it just blindly did this with the assumption all stack and heap memory
was executable - thus making it cause exec-shield to be disabled.  In XFree86
4.3.0 we had a custom Red Hat patch which made Mesa properly set up the memory
to work nicely with exec-shield, however the patch was dropped due to being
to much effort to forward port to every new release, and the code was rejected
upstream.

My understanding is that upstream has eventually re-implemented this in
the mesa currently in rawhide, and that it now properly takes care of
ensuring the memory it allocates is flagged PROT_EXEC when need be.

If I'm reading your question right, the answer would be that Mesa does
require dynamically allocated executable memory in order to have functional
DRI support.

Do you need any further info?
Comment 2 Russell Coker 2006-01-20 10:43:38 EST
Surely if it's only the drivers that allocate such memory then only those 
drivers need to be marked as requiring write/execute access?  This would mean 
that if you use a driver that needs such access then the access is granted, 
otherwise it isn't, while the current system grants such access even if no DRI 
drivers need it. 
 
Comment 3 Mike A. Harris 2006-01-20 12:14:28 EST
I'm probably not the best person to ask, as I'm not really intimately
involved with the Mesa code.  Ajax or krh can likely best respond.
Comment 4 Ulrich Drepper 2006-01-20 22:24:34 EST
Jakub fixed mesa some time back.  The first question is why isn't that patch
carried forward?  It's a *HUGE* security risk to not do this because all those
crappy desktop apps are linked against libGL.  It's also a big step backward
security-wise from previous versions of the distribution.

I do not really know whether the problem was in libGL itself or in the modules
which are loaded.  Now that dlopen is used it is in theory indeed possible to
mark only the modules requiring the executable stack as such and not libGL.

I added Jakub to the cc list, he would know.
Comment 5 Mike A. Harris 2006-01-31 18:58:09 EST
(In reply to comment #4)
> Jakub fixed mesa some time back.  The first question is why isn't that patch
> carried forward?

Jakub submitted it to Mesa upstream at one point, and it was rejected, or
perhaps just ignored, I'm not completely sure.  You might want to ask jakub
directly though, as he probably has a better recollection.

Porting patches forward every single OS release, in particular for something
like Mesa which changes drastically every X release, is not viable from
an engineering resource management/allocation perspective, in particular
considering how strained our existing X development resources have been.

It is a general policy of the X Development team, and has been for a very
long time now, that any nontrivial work that is done, must be completed,
submitted upstream by the author, and accepted into upstream CVS before
we will consider including it in our packaging.  This is a policy that
was "defacto" for quite a while, but was put in place as an official policy
by our team leader (kem) during development of various team policies.


> It's a *HUGE* security risk to not do this because all those
> crappy desktop apps are linked against libGL.

Of course I'd agree with you on that.

> It's also a big step backward security-wise from previous versions of the
> distribution.

Only from a single version:  Red Hat Linux 9.

If memory serves me correctly, that is the only OS release which has ever
shipped with the custom Mesa patch.  In retrospect, it was a mistake to
include such a large custom patch at all, until it had been submitted and
accepted by Jakub to the Mesa project.


> I do not really know whether the problem was in libGL itself or in the modules
> which are loaded.  Now that dlopen is used it is in theory indeed possible to
> mark only the modules requiring the executable stack as such and not libGL.

We are currently not doing anything special to build Mesa that would cause
libGL to be flagged with an executable stack.  I discussed this with ajax
last week, and I believe he indicated that the "linux-dri-x86" build
target will require GNU stacks for some performance reason, but that
the "linux-dri" target doesn't require it.

I think we can all agree that having libGL not require an executable stack,
is beneficial security-wise.  I'd also agree that the DRI modules that
require exec-stack should be the only thing that is flagged in that manner.

I don't find it very beneficial in solving this problem to complain about
past decisions that were made, or to wave fingers at people.  Let's please
just focus on solving the problems for once and for all, in a manner that
is not going to cause us long term maintenance problems (such as a large
custom patch we have to port forward every OS release).

It shouldn't be difficult to solve this properly for FC5, so I'm adding it
to the FC5Target list.
Comment 6 Mike A. Harris 2006-01-31 19:12:17 EST
Additionally, I'd like to point out that the problem that the old
exec-stack patch fixed, was ensuring memory allocated in the DRI
drivers got flagged PROT_EXEC.  That is all it did, and that is
already in Mesa that is in rawhide.  The problem being surfaced
in _this_ bug report, is an entirely new problem which never existed
in previous OS releases to the best of my knowledge.  So kicking sand
over an ancient problem that appears to have been resolved ever
since Mesa 6.4.x hit rawhide, isn't useful.
Comment 7 Guy Streeter 2006-02-07 17:21:01 EST
Is there a workaround for this, so I can use libGL.so?
Comment 8 Miles Lane 2006-02-17 02:41:04 EST
I guess I am hitting this problem?
amarokapp: error while loading shared libraries: libGL.so.1: cannot enable
executable stack as shared object requires: Permission denied
Comment 9 Jarkko 2006-02-22 02:18:26 EST
The upgrade which broke my metacity:

$ sudo grep mesa-libGL /var/log/yum.log
Feb 22 05:48:09 Updated: mesa-libGL.i386 6.4.2-3
Feb 22 05:49:58 Updated: mesa-libGLU.i386 6.4.2-3
Feb 22 05:54:27 Updated: mesa-libGLw.i386 6.4.2-3


The problem with metacity:

$ metacity
metacity: error while loading shared libraries: libGL.so.1: cannot
enable executable stack as shared object requires: Permission denied


The fix:

# execstack -c /usr/lib/libGL.so.1


The problematic package:

# rpm -q --whatprovides /usr/lib/libGL.so.1
mesa-libGL-6.4.2-3
Comment 10 Adam Jackson 2006-03-06 21:54:49 EST
i believe the only dynamic code generation Mesa does these days is done on the
heap and/or in its own writable text section, and not on the stack.
Comment 11 Jakub Jelinek 2006-03-07 01:38:36 EST
But heap isn't executable either when PT_GNU_STACK program header says PT_R|PT_W.
Unless Mesa explicitly mmaps the memory for dynamically generated code with
PROT_EXEC (or better, yet, creates with PROT_READ|PROT_WRITE and when done
mprotects with PROT_READ|PROT_EXEC), things won't work properly.
Comment 12 Mike A. Harris 2006-03-07 07:13:54 EST
*** Bug 182380 has been marked as a duplicate of this bug. ***
Comment 13 Adam Jackson 2006-03-07 10:37:39 EST
(In reply to comment #11)
> But heap isn't executable either when PT_GNU_STACK program header says PT_R|PT_W.
> Unless Mesa explicitly mmaps the memory for dynamically generated code with
> PROT_EXEC (or better, yet, creates with PROT_READ|PROT_WRITE and when done
> mprotects with PROT_READ|PROT_EXEC), things won't work properly.

yes, i believe it does the mprotect method now, even for the -x86 build target.
 i'll check of course.
Comment 14 Ulrich Drepper 2006-03-25 11:05:07 EST
Re comment #5:

> Porting patches forward every single OS release, in particular for something
> like Mesa which changes drastically every X release, is not viable from
> an engineering resource management/allocation perspective,

I do not agree at all.  You cannot insist on a pristine package if upstream
isn't willing to pick up critical patches.  This is the way things work.  Every
package maintainer has such patches they'd like to get rid of.

We have to set priorities and GL disabling all the security features for the
entire desktop is simply no option IMO.  Yes, it might mean more resource
requirements on our side (esp the X team) but this is a crucial part of the
security of the system.  As Mark's analysis showed, 100% of the security
problems of RHEL4's first year are in the desktop programs, not the server side.

I'm not saying Jakub patch does everything it now has to do and therefore it's
easy to integrate.  It's rather unlikely, the original patch mainly dealt with
the stack and perhaps not using malloc for executable memory.  The situation now
is more complicated.  You must avoid PROT_WRITE^PROT_EXEC mprotect.  You cannot
even change PROT_WRITE to PROT_EXEC.  It's explained at

http://people.redhat.com/drepper/selinux-mem.html

That page also has some code explaining how to best solve the problem.
Comment 15 Mark J. Cox (Product Security) 2006-03-31 09:59:43 EST
> Porting patches forward every single OS release, in particular for something
> like Mesa which changes drastically every X release, is not viable

I totally agree with Uli.  There are in RHEL, as well as FC, a number of
security patches in packages that we carry forward each time due to them not
being acceptable for whatever reason upstream.  We are accountable for the risk
our customers face using our distributions, and therefore responsible for doing
everything we can to minimise that risk,  even if upstream doesn't agree or it
involves us doing some engineering work at the expense of other fixes or it's
hard.  

Anyway this issue is no longer about patches being missed, it's a new issue, so
it's something we need to fix in an update and then keep carrying forward if
upstream reject it.
Comment 16 Adam Jackson 2006-04-19 13:10:23 EDT
fixed in rawhide, iirc...
Comment 17 Adam Jackson 2006-06-23 16:38:13 EDT
Backported the rawhide noexec-stack fixes to FC5 as of mesa-6_4_2-6_FC5_2. 
Update pending.

The fix is already in upstream Mesa, and should be included in 6.5.1 and later.
Comment 18 Adam Jackson 2006-06-23 17:14:17 EDT
*** Bug 191191 has been marked as a duplicate of this bug. ***
Comment 19 Fedora Update System 2006-06-26 19:02:33 EDT
mesa-6.4.2-6.FC5.3 has been pushed for fc5, which should resolve this issue.  If these problems are still present in this version, then please make note of it in this bug report.
Comment 20 Mike A. Harris 2006-06-27 13:52:48 EDT
From comment #17, I assume this is already fixed in rawhide currently?

The mesa update for FC5 already went out the door.  This should be closed
as "RAWHIDE" now if it's fixed I suppose.
Comment 21 Adam Jackson 2006-06-27 14:07:35 EDT
(In reply to comment #20)
> The mesa update for FC5 already went out the door.  This should be closed
> as "RAWHIDE" now if it's fixed I suppose.

ACK, fixed in rawhide.
Comment 22 Fedora Update System 2006-06-28 09:46:34 EDT
mesa-6.4.2-6.FC5.3 has been pushed for fc5, which should resolve this issue.  If these problems are still present in this version, then please make note of it in this bug report.

Note You need to log in before you can comment on or make changes to this bug.