Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
Bug 147563 - X module loader doing mprotect() on the heap
Summary: X module loader doing mprotect() on the heap
Alias: None
Product: Fedora
Classification: Fedora
Component: xorg-x11
Version: rawhide
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: X/OpenGL Maintenance List
QA Contact: David Lawrence
Depends On:
Blocks: FC5Target
TreeView+ depends on / blocked
Reported: 2005-02-09 11:24 UTC by Ingo Molnar
Modified: 2007-11-30 22:11 UTC (History)
4 users (show)

Fixed In Version:
Doc Type: Enhancement
Doc Text:
Clone Of:
Last Closed: 2006-01-27 10:58:10 UTC

Attachments (Terms of Use)

Description Ingo Molnar 2005-02-09 11:24:35 UTC
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:

Steps to Reproduce:
1. start X

Actual Results:  X crashes.

Expected Results:  X works fine.

Additional info:

Comment 1 Mike A. Harris 2005-02-11 17:33:04 UTC
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

I'll bring this up on a future X devel team confcall to discuss

Comment 2 Roland McGrath 2005-02-11 20:42:02 UTC
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 15:18:16 UTC
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 15:20:49 UTC
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 10:58:10 UTC
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-02-01 01:42:51 UTC
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.