[bugs #9169] libgnustep-base 1.7.2 dies due to mprotect() call

[Fred Kiefer]

This mail is an automated notification from the bugs tracker
 of the project: GNUstep.

/**************************************************************************/
[bugs #9169] Latest Modifications:

Changes by: 
                Fred Kiefer <FredKiefer@gmx.de>
'Date: 
                Thu 06/03/2004 at 22:21 (GMT)

------------------ Additional Follow-up Comments ----------------------------
Could you please try with libffi instead of ffcall? I am not saying that this 
will remove the problem, but it is worth trying.






/**************************************************************************/
[bugs #9169] Full Item Snapshot:

URL: <http://savannah.gnu.org/bugs/?func=detailitem&item_id=9169>
Project: GNUstep
Submitted by: 0
On: Sun 05/30/2004 at 23:21

Category:  Libraries
Severity:  5 - Average
Item Group:  Bug
Resolution:  None
Assigned to:  None
Status:  Open


Summary:  libgnustep-base 1.7.2 dies due to mprotect() call

Original Submission:  I'm trying to use the NSObject base class and whenever I 
do, programs I compile die because of the error:

trampoline: cannot make memory executable

I've checked each and every library that my hello world program is linked to, 
and only libgnustep-base.so.1 contains the 'cannot make memory executable' 
string:

bluefox@icebox tests $ grep -iHnr --mmap "cannot make memory executable" 
/usr/GNUstep/System/Library/Libraries/libgnustep-base.so.1
Binary file /usr/GNUstep/System/Library/Libraries/libgnustep-base.so.1 matches

The issue here is that I'm using a certain security system, called PaX, which 
deals executable space protection.  In this case, it is one of the systems that 
prevents code injection which is killing it:  mprotect() restrictions.

Under PaX' mprotect() policy, no pages may become executable; they must always 
be created with PROT_EXEC and *not* PROT_WRITE (i.e. when a shared object is 
mapped in), or without PROT_EXEC (i.e. malloc()ed ram or mmap()ed anonymous 
memory, or read/write disk mappings).  Pages may lose PROT_EXEC if you so 
choose.

PaX appears to not be able to catch the trampolining being done with its 
trampoline emulation.  Although this can be 'fixed' on the PaX side, trampoline 
emulation is off by default for security reasons; and so far this is the only 
time I've actually had to enable it on anything.  Both the issue of PaX not 
catching the trampoline, and the issue of libgnustep-base having a trampoline 
need to be addressed.

Please deal with this issue at your leisure; however, I would appreciate it if 
you did not simply let it rot.  For now I can work around it, but this is in no 
way proper.

Follow-up Comments
------------------


-------------------------------------------------------
Date: Thu 06/03/2004 at 22:21       By: FredKiefer
Could you please try with libffi instead of ffcall? I am not saying that this 
will remove the problem, but it is worth trying.

-------------------------------------------------------
Date: Sun 05/30/2004 at 23:24       By: None
===
PaX appears to not be able to catch the trampolining being done with its 
trampoline emulation. Although this can be 'fixed' on the PaX side, trampoline 
emulation is off by default for security reasons; and so far this is the only 
time I've actually had to enable it on anything. Both the issue of PaX not 
catching the trampoline, and the issue of libgnustep-base having a trampoline 
need to be addressed.
===

Sorry, I meant to say, this *would* be the first time I've had to enable it; I 
have to turn OFF the mprotect() restrictions to accomodate the trampoline, 
which means I'm leaving an even bigger security hole until PaX can catch the 
trampoline if it can at all.












For detailed info, follow this link:
<http://savannah.gnu.org/bugs/?func=detailitem&item_id=9169>

_______________________________________________
  Message sent via/by Savannah
  http://savannah.gnu.org/