public inbox for libffi-discuss@sourceware.org
 help / color / mirror / Atom feed
From: "Kaz Kylheku (libffi)" <382-725-6798@kylheku.com>
To: Andrew Haley <aph@redhat.com>
Cc: libffi-discuss@sourceware.org
Subject: Re: is fork() supported?
Date: Wed, 25 Aug 2021 09:59:05 -0700	[thread overview]
Message-ID: <8a8c093795597dcc8e71e844e235a57d@mail.kylheku.com> (raw)
In-Reply-To: <4da1a4e5-fbac-5d5f-b5ee-abe0b252ed80@redhat.com>

On 2021-08-25 02:27, Andrew Haley via Libffi-discuss wrote:
> 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.

It's *a* way to do it, but tweaking the address space so that it looks
different in different threads seems extremely wrong and repugnant.

The threads of a process should live in exactly the same address space,
in every detail: every page, every protection bit.

There should be no TLB switching/flushing when we task switch from
one thread to another in the same process.

Of course, this is just another requirement, and no requirement
is absolutely non-negotiable otherwise otherwise we have religion
and not engineering.

However, this is a pretty firm, fundamental thing, I would think!

If it was done without actually making different memory maps per
thread that would be great.

For instance, suppose the mapping that is opened up for writing for
one thread is actually write protected to all threads. What happens
is this:

1. The "blessed" thread which owns the JIT mapping performs a write.
2. This traps into the kernel.
3. The kernel sees, aha, this is the blessed thread which is allowed
    to write.
4. The kernel emulates the write.
5. The thread's instruction pointer and other machine state is fixed
    up to look like it had done the write.
6. The thread is restarted.

If the thread is not the blessed one, a fatal signal is generated,
as usual.

One the JITted code is installed, the blessedness goes away; all
threads bomb if they write access it.

Prior art for this, is obviously, things like simulating misaligned
memory accesses on machines that trap on misalignment.

The downside is that it's slow for writing a large amount of JIT
material. Though installation of JIT material is amortized over the
cost of compiling it in the first place, that may still be
unacceptable overhead. (Also, it's not always amortized. Some
ahead-of-time compiling situations would also use this mechanism;
JIT is just a convenient acronym. Not all code loading is done by
mapping directly into memory. In some languages, an code object
might be read containing the executable code as a blob literal,
which is then installed as if it came from JIT).

Really, you need a dedicated write-like syscall for this, which the
blessed thread can use to specify the bytes to be written to the
JIT memory. That is similar to the solution involving writes to
a file, except there is no file.

In Linux, a possible place to dump this this might be oh, let's see,
prctl?

   prctl(PR_WRITE_JIT, (long) dst, (long) src, (long) size);

[dst, dst + size) must be a MAP_JIT mapping indicating the
calling thread as being blessed, otherwise it fails.



  parent reply	other threads:[~2021-08-25 16:59 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
2021-08-25 16:59                 ` Kaz Kylheku (libffi) [this message]
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=8a8c093795597dcc8e71e844e235a57d@mail.kylheku.com \
    --to=382-725-6798@kylheku.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).