Bug 399 - executable code in data areas must be marked executable
Summary: executable code in data areas must be marked executable
Status: RESOLVED DUPLICATE of bug 395
Alias: None
Product: xorg
Classification: Unclassified
Component: Server/General (show other bugs)
Version: git
Hardware: x86 (IA32) Linux (All)
: high blocker
Assignee: Xorg Project Team
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks: 213
  Show dependency treegraph
 
Reported: 2004-04-01 13:00 UTC by John Dennis
Modified: 2004-04-02 07:41 UTC (History)
2 users (show)

See Also:
i915 platform:
i915 features:


Attachments
mark data areas as executable in various places (17.62 KB, patch)
2004-04-01 13:01 UTC, John Dennis
no flags Details | Splinter Review

Note You need to log in before you can comment on or make changes to this bug.
Description John Dennis 2004-04-01 13:00:18 UTC
With a greater emphasis on security some OS's are not allowing processors to
execute code in data areas, the default behavior is to only allow code to
execute in text segments. Programs that perform runtime generation of code run
afoul of this restriction with the result their process is aborted by the OS.
Various parts of X, Mesa, and DRI generate executable code in data areas, some
of these have been fixed, but others have been missed. This patch addresses
these omisssions. The Mesa fixes may need to be propaged into their project (I
will open a Mesa bug and point it here).

With respect to this patch please make note of the following: 

Documentation can be found in the file mem.c, it explains various options,
choices, alternate implementations, and why the final solution was picked.

This problem is common to many software components, I don't think this patch is
the optimal solution as it tends to attack things piecemeal, in some cases just
duplicating the same code. It would be better to have a single memory allocator
for executable memory, but that is beyond the scope of an immediate short term
solution.
Comment 1 John Dennis 2004-04-01 13:01:25 UTC
Created attachment 171 [details] [review]
mark data areas as executable in various places
Comment 2 Mike A. Harris 2004-04-01 14:40:52 UTC
Just a note for whoever investigates this, that the changes to:

xc/programs/Xserver/hw/xfree86/loader/elfloader.c

are also part of:

http://freedesktop.org/cgi-bin/bugzilla/show_bug.cgi?id=395


I would lop that off of this patch, as the rest of this patch is specifically
Mesa related, whereas that portion is part of the ELF loader, and covered
by the other bug report.
Comment 3 Bugzilla Maintainer 2004-04-02 08:58:45 UTC
We'd like to see the Mesa patch come in through the Mesa project; please submit
that part of this patch to them if you haven't already.

The elfloader.c changes are already present in bug #395, so I'm marking this as
a duplicate of that bug.

*** This bug has been marked as a duplicate of 395 ***
Comment 4 Mike A. Harris 2004-04-03 01:41:46 UTC
I agree that the Mesa portion needs to be merged upstream, and it is probably
a good idea to get it merged there first, so that it doesn't have to be
carried forward.  John submitted it upstream to Mesa/DRI folks recently whom
indicated that they are going to merge it into Mesa soon, which is a good
sign.  ;o)

It would still be a good idea to get John's patch merged into X.org though,
if not right away, then perhaps at least once it is confirmed to be in the
Mesa tree.  Otherwise there will probably be an increase of users reporting
DRI and/or X server crashing bugs when running on systems that disable
stack/heap execution by default.  Currently that includes Fedora Core 1,
Fedora Core 2 testX, and I believe also Gentoo, and possibly other Linux
distributions are also starting to use the new exec-shield functionality
or similar.  OpenBSD aparently has similar.

Just a heads up that there might be an increase of bugs reported without
this or similar patches in the Xorg tree.  ;oP


Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.