Bug 147563 - X module loader doing mprotect() on the heap
X module loader doing mprotect() on the heap
Status: CLOSED RAWHIDE
Product: Fedora
Classification: Fedora
Component: xorg-x11 (Show other bugs)
rawhide
All Linux
medium Severity medium
: ---
: ---
Assigned To: X/OpenGL Maintenance List
David Lawrence
: FutureFeature, Triaged
Depends On:
Blocks: FC5Target
  Show dependency treegraph
 
Reported: 2005-02-09 06:24 EST by Ingo Molnar
Modified: 2007-11-30 17:11 EST (History)
4 users (show)

See Also:
Fixed In Version:
Doc Type: Enhancement
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2006-01-27 05:58:10 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)

  None (edit)
Description Ingo Molnar 2005-02-09 06:24:35 EST
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040510

Description of problem:

the SELinux folks are trying to introduce mprotect() API restrictions.
One variant of those restrictions is to not allow mprotect() on
writable mappings.

A modified version of Roland McGrath's kernel patch to rhselinux-list
shows that X is mprotect()-ing what seems to be malloc() areas:

 #2 X/2943: 0822f000-08232000 (00100077).
 #2 X/2943: 08232000-0824a000 (00100073).



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


How reproducible:
Always

Steps to Reproduce:
1. start X
2.
3.
    

Actual Results:  X crashes.

Expected Results:  X works fine.

Additional info:
Comment 1 Mike A. Harris 2005-02-11 12:33:04 EST
The Xorg ELF loader is the culprit here.  We enhanced the ELF loader
a year or two ago to call mprotect to flag memory regions with
PROT_EXEC in order for the X server to work with exec-shield.

The upstream X.Org project is currently planning on disabling the
ELF loader in X11R7, and using the dlopen loader instead, which
will have a nice side effect of resolving this issue, however
that wont likely be until the Fedora Core 5 / RHEL 5 timeframe.

If this feature request is intended for FC4 and/or RHEL4_Un updates,
we'll need to evaluate the ELF loader to determine how much effort
it might take to rework it to not require mprotect.

I've CC'd John Dennis, as I believe he did the mprotect
enhancements initially, and might be able to provide some useful
comments.

I'll bring this up on a future X devel team confcall to discuss
also.
Comment 2 Roland McGrath 2005-02-11 15:42:02 EST
To be clear, it is perfectly fine to be using mprotect.
The issue is the use of mprotect on memory from malloc, sbrk, or static memory
regions such as big global arrays.  That's what appears to be happening.
If the loader allocates memory with mmap and then uses mprotect on that, this
should not be a problem.  Of course it can then just use the protection bits in
needs in the original mmap call.
Comment 3 John Dennis 2005-02-14 10:18:16 EST
I'm going on memory here with respect to how the code works, but I'm pretty sure
it does call mprotect on memory obtained from malloc. I'm not sure its worth
trying to rewrite the code if the X ELF loader can be replaced with dlopen. So
this might boil down to an issue of timing as to when the dlopen version the X
server is available.
Comment 4 John Dennis 2005-02-14 10:20:49 EST
Oh, almost forgot, its not just the X server which is setting execute permission
on memory. DRI and the OpenGL client library also does it.
Comment 11 Mike A. Harris 2006-01-27 05:58:10 EST
This should all be resolved now with X11R7 in Fedora Core 5.  If there
are any remaining issues, they should be reported in X.Org bugzilla and
tracked there.

Setting status to "RAWHIDE"
Comment 12 Ulrich Drepper 2006-01-31 20:42:51 EST
So, can somebody plase make sure the now unnecessary permissions are removed
from the SELinux policy?

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