public inbox for libffi-discuss@sourceware.org
 help / color / mirror / Atom feed
From: Jay K <jayk123@hotmail.com>
To: "libffi-discuss@sourceware.org" <libffi-discuss@sourceware.org>,
	Andrew Haley <aph@redhat.com>
Subject: Re: is fork() supported?
Date: Wed, 25 Aug 2021 15:58:05 +0000	[thread overview]
Message-ID: <MWHPR1401MB1951DABFB020BABBD6C81CE9E6C69@MWHPR1401MB1951.namprd14.prod.outlook.com> (raw)
In-Reply-To: <4da1a4e5-fbac-5d5f-b5ee-abe0b252ed80@redhat.com>

 > pthread_jit_write_protect_np

It is all tradeoffs I think.
Attacker can still try to write to the pages while they are writable,
in any of the approaches (Apple, two mappings, two processes, etc.)

But yes that does of course help.

But I again I think all those methods, including the Apple one,
are needed only for "arbitrary" code gen, not codegen that can be made
data driven (n thunks, array of n to drive them), and the code is
therefore constant, and there "just" needs to be
a way to make multiple copies/mappings of it (to expand the pool of
n by another n).

vm_remap is the Apple function I was thinking of.

 - Jay

________________________________
From: Libffi-discuss <libffi-discuss-bounces+jay.krell=cornell.edu@sourceware.org> on behalf of Andrew Haley via Libffi-discuss <libffi-discuss@sourceware.org>
Sent: Wednesday, August 25, 2021 9:27 AM
To: libffi-discuss@sourceware.org <libffi-discuss@sourceware.org>
Subject: Re: is fork() supported?

On 8/24/21 10:58 PM, Jay K via Libffi-discuss wrote:

> I believe MacOSX also has this as an extension like this, in that
> instead of giving an fd to map, you can give an address, to another
> function, I cannot find the name. This can be used, I guess, to
> avoid remapping the entire .so.

Mac solves the problem in a much nicer way, one that is JIT-friendly
but does not allow pages to be both W and X.

Here's how it works:

    Call mmap with the MAP_JIT option to create a memory region for
    the new machine instructions.

    Call pthread_jit_write_protect_np() with the value false to disable
    JIT write protections for the memory region in the current thread.

    Write the machine instructions to the memory region.

Note that this is *per thread*. other threads will simply continue to
execute code in the JITted region. The JIT can generate code, but can
not execute any JITted code until it calls
pthread_jit_write_protect_np(true). Of course this requires threads to
have differently-mapped regions. It would be very nice to have in
Linux. It is the right way to do it.

https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdeveloper.apple.com%2Fdocumentation%2Fapple-silicon%2Fporting-just-in-time-compilers-to-apple-silicon&amp;data=04%7C01%7C%7C8e3a0f2a2e084358a7f708d967aa962f%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637654804622490592%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=%2FCuwk5zssydzfZqBgj9q%2BCt32dJ07Y8DyvEoRwZ2ZhI%3D&amp;reserved=0

--
Andrew Haley  (he/him)
Java Platform Lead Engineer
Red Hat UK Ltd. <https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.redhat.com%2F&amp;data=04%7C01%7C%7C8e3a0f2a2e084358a7f708d967aa962f%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637654804622490592%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=6hzVYMKexxJS2Rj39mZMOzsuh3F%2FF6fI1RSEYgFjk9Q%3D&amp;reserved=0>
https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fkeybase.io%2Fandrewhaley&amp;data=04%7C01%7C%7C8e3a0f2a2e084358a7f708d967aa962f%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637654804622500585%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=9h6U8eCdUgolrNdQgPDktROXmT2J1JMhchU4DJYAOyg%3D&amp;reserved=0
EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671


  reply	other threads:[~2021-08-25 15:58 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-08-04 20:00 DJ Delorie
2021-08-05  8:17 ` Andrew Haley
2021-08-05  8:27   ` Florian Weimer
2021-08-24 18:15     ` DJ Delorie
2021-08-24 18:27       ` Jay K
2021-08-24 18:45         ` DJ Delorie
2021-08-24 21:12           ` Kaz Kylheku (libffi)
2021-08-24 21:58             ` Jay K
2021-08-25  9:27               ` Andrew Haley
2021-08-25 15:58                 ` Jay K [this message]
2021-08-25 16:59                 ` Kaz Kylheku (libffi)
2021-08-25 21:17                   ` Andrew Haley
2021-08-05 18:13   ` DJ Delorie
2021-08-05 21:21     ` Jay K
2021-08-06  8:32       ` Andrew Haley

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=MWHPR1401MB1951DABFB020BABBD6C81CE9E6C69@MWHPR1401MB1951.namprd14.prod.outlook.com \
    --to=jayk123@hotmail.com \
    --cc=aph@redhat.com \
    --cc=libffi-discuss@sourceware.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).