buglibffcall - foreign function call libraries - Bugs: bug #66089, On macos 14, mmap with PROT_READ |...

 
 

bug #66089: On macos 14, mmap with PROT_READ | PROT_EXEC fails

Submitter:  Lorenzo Daneo <lorespaul>
Submitted:  Wed 14 Aug 2024 03:32:14 PM UTC
   
 
Category:  None Severity:  3 - Normal
Item Group:  crash Status:  Fix Released
Privacy:  Public Assigned to:  haible
Open/Closed:  Closed
* Mandatory Fields

Add a New Comment Rich Markup
   

Jump to the original submission

Mon 02 Sep 2024 01:32:12 PM UTC, comment #9: 

The fix is contained in GNU libffcall 2.5.

Bruno Haible <haible>
Group administrator
Mon 26 Aug 2024 08:30:25 AM UTC, comment #8: 

Lorenzo Daneo wrote in https://lists.gnu.org/archive/html/libffcall/2024-08/msg00013.html:

> I tried the prerelease package and it works.


Thanks for testing. Marking as fixed.

Bruno Haible <haible>
Group administrator
Sat 17 Aug 2024 10:23:10 PM UTC, comment #7: 

Please test the prerelease tarball https://alpha.gnu.org/gnu/libffcall/libffcall-2.4.91.tar.gz. Does it work for you, in your application (main -> init_game -> create_deck), on macOS 14?

Bruno Haible <haible>
Group administrator
Sat 17 Aug 2024 10:20:29 PM UTC, comment #6: 

Updating the title to reflect the actual problem description in https://lists.gnu.org/archive/html/libffcall/2024-08/msg00007.html

Bruno Haible <haible>
Group administrator
Thu 15 Aug 2024 04:29:24 AM UTC, comment #5: 

Lorenzo Daneo wrote in https://lists.gnu.org/archive/html/libffcall/2024-08/msg00009.html:

> The errno is 1 (Operation not permitted).


So, EPERM. Thanks.

Bruno Haible <haible>
Group administrator
Wed 14 Aug 2024 06:33:01 PM UTC, comment #4: 

Lorenzo Daneo wrote in https://lists.gnu.org/archive/html/libffcall/2024-08/msg00007.html:

> I just tried to recompile with HAVE_MMAP_SHARED_CAN_EXEC = 1
> and HAVE_MPROTECT_AFTER_MMAP_CAN_EXEC = 0

Yes, that's what one needs to look at.

> page = (char)mmap(NULL,pagesize,PROT_READ|PROT_WRITE,MAP_SHARED,file_fd,file_length);*
> *page_x =

(char*)mmap(NULL,pagesize,PROT_READ|PROT_EXEC,MAP_SHARED,file_fd,file_length);*

>
> The second mmap is not working.


What is the value of errno after the assignment to page_x ?

Bruno Haible <haible>
Group administrator
Wed 14 Aug 2024 06:09:47 PM UTC, comment #3: 

Lorenzo Daneo wrote in https://lists.gnu.org/archive/html/libffcall/2024-08/msg00003.html :

> the installation with brew was going in error at line 87 in trampoline.c


On macOS, HAVE_MMAP_SHARED_CAN_EXEC is supposed to be defined to 1.

Can you please look in the config.log what happened to the "checking whether a shared mmap can make memory pages executable..." test? This test ought to succeed.

> compiled locally with HAVE_MPROTECT_AFTER_MMAP_CAN_EXEC set to 1


This won't work. The reason HAVE_MMAP_SHARED_CAN_EXEC was introduced is that, precisely, mprotect (PROT_READ|PROT_WRITE|PROT_EXEC) does not work on macOS and some other operating systems.

Bruno Haible <haible>
Group administrator
Wed 14 Aug 2024 05:08:32 PM UTC, comment #2: 

Also:

Which version of libffcall are you using?

What exactly is the scenario (test program) that causes the SIGABRT on macOS?

I'm asking because my continuous integration of libffcall shows no problems on macOS versions 12, 13, 14: https://github.com/gnu-libffcall/ci-check/actions

Bruno Haible <haible>
Group administrator
Wed 14 Aug 2024 04:28:26 PM UTC, comment #1: 

Thanks for the report.

On which version of macOS do you see this?

When a SIGABRT occurs, what is the stack trace? (I know macOS makes it impossible to use a debugger. But what stack trace do you get by using libbacktrace https://github.com/ianlancetaylor/libbacktrace and the gnulib module 'abort-debug'?)

> If you want I can ... make a pull request.


We don't work with pull requests here. Instead we work with patches, either attached to a ticket like here, or sent to the mailing list.

Bruno Haible <haible>
Group administrator
Wed 14 Aug 2024 03:32:14 PM UTC, original submission:  

As stated in the title, PROT_WRITE|PROT_EXEC cannot be passed to mprotect (at least on macos). This causes the process to SIGABRT.
I have a fix ready. If you want I can push it to a branch in the github repository (https://github.com/roswell/libffcall) and make a pull request.
Thanks,
Lorenzo

Lorenzo Daneo <lorespaul>

 

(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 haible (Posted a comment)
  • -email is unavailable- added by lorespaul (Submitted the item)
  •  

    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 8 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2024-09-02 haible StatusFixed Fix Released
    2024-08-26 haible StatusReady For Test Fixed
        Open/ClosedOpen Closed
    2024-08-17 haible StatusNone Ready For Test
    2024-08-17 haible SummaryOn macos mprotect can't be PROT_WRITE and PROT_EXEC at the same time On macos 14, mmap with PROT_READ | PROT_EXEC fails
    2024-08-15 haible StatusNeed Info None
    2024-08-14 haible StatusNone Need Info
        Assigned toNone haible

    Back to the top

    Powered by Savane 3.15-e6e5.
    Corresponding source code