bugGNUstep - Bugs: bug #9169, libgnustep-base 1.7.2 dies due to...

Group
 
 

bug #9169: libgnustep-base 1.7.2 dies due to mprotect() call

Submitter:  None
Submitted:  Sun 30 May 2004 11:21:20 PM UTC
   
 
Category:  Libraries Severity:  3 - Normal
Item Group:  Bug Status:  Invalid
Privacy:  Public Assigned to:  fedor
Open/Closed:  Closed
* Mandatory Fields

Add a New Comment Rich Markup
   

Mon 19 Mar 2007 03:32:41 AM UTC, comment #3: 

Sorry, this is really a bug in ffcall, and it appeasr to really be fundamental to the way ffcall functions.  I'd recommend trying to use libffi as well.

There's a ffcall bug report for this (1531290) at
http://sourceforge.net/tracker/?group_id=1355&atid=101355
 if you want to follow this (it's been open for several months with no action though).

Adam Fedor <fedor>
Group administrator
Thu 03 Jun 2004 10:21:07 PM UTC, comment #2: 

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

Fred Kiefer <FredKiefer>
Group Member
Sun 30 May 2004 11:24:07 PM UTC, comment #1: 

===
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.

Anonymous
Sun 30 May 2004 11:21:20 PM UTC, 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.

Anonymous

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:
   
   
Comment:
   

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by fedor (Posted a comment)
  •  

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

    Only logged-in users can vote.

     

    Follow 3 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2007-03-19 fedor StatusNone Invalid
        Assigned toNone fedor
        Open/ClosedOpen Closed

    Back to the top

    Powered by Savane 3.13-d3ae.
    Corresponding source code