is fork() supported?

[Jay K]

I have used the multi-mmap of static code in another project.

Can libffi not always do that?

 > The problem case is when libffi can't mmap a chunk of write+exec memory,

Why does it need to, given the multi-mmap of static trampoline approach?

 > Isn't there some way way set up two anonymous, virtual regions such
 > that they alias to the same frames? One can be read+exec, and the other write.

People speak of "arbitrary codegen" (ACG) or unspecififically "JIT", and
"something else", I have never seen a name for, "non-arbitrary codegen"?,
the scenario where there is static code, and it can be mapped multiple times.

In ACG, the two mapping approach is used by some systems.
The writable address may be "difficult" for an attacker to find.
It ups the arms race, some. I cannot quantify that.

The writing might also be done from another process (in Windows
this is "easy", at the API level, given an adequately factored JIT..
I realize the double whammy here, of both likely different addresses
and address spaces, on existing code).

The executing process might even be prohibited from having the writable alias,
which is surely a very nice escalation.

But, all that aside, given the recent work in libffi, the follow-up
to "trampfd", why is a writable mapping every needed?

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.

Thank you,
 - Jay

________________________________
From: Kaz Kylheku (libffi) <382-725-6798@kylheku.com>
Sent: Tuesday, August 24, 2021 9:12 PM
To: DJ Delorie <dj@redhat.com>
Cc: Jay K <jayk123@hotmail.com>; libffi-discuss@sourceware.org <libffi-discuss@sourceware.org>; Libffi-discuss <libffi-discuss-bounces+382-725-6798=kylheku.com@sourceware.org>
Subject: Re: is fork() supported?

On 2021-08-24 11:45, DJ Delorie via Libffi-discuss wrote:
> Jay K <jayk123@hotmail.com> writes:
>> 1 Sorry, I assumed mail from DJ was about djgpp, and that context was
>> lacking in libffi. My mistake.
>
> Ha!  Yeah, not about djgpp, which I think "just works" ;-)
>
>> 3 So libffi no longer has read/write/execute memory, or turns
>> read/write into execute, correct?
>
> The problem case is when libffi can't mmap a chunk of write+exec
> memory,
> and resorts to writing to a file and mapping the file read+exec, which
> happens in Linux with certain selinux security profiles.

Isn't there some way way set up two anonymous, virtual regions such that
they alias to the same frames? One can be read+exec, and the other
write.

I could easily write code in the kernel to take some user space pages
of the calling process and make them also appear somewhere else in
the address space.

I don't see anything like that in the Linux mmap among any of the flags
and whatnot.

It would be a useful extension.

Imagine a MAP_ALIAS flag, which requires the void *addr argument to be
present. addr, normally used with MAP_FIXED, in this case would specify
the virtual address of the target range to be aliased by the returned
mapping.

Being able to obtain a writable alias of executable space is
a security risk though: the risk that an attacker can inject a mmap
call to create an writable alias of executable space.
Some new PROT_* bit could help mitigate: the read+exec mapping would
have
this bit to indicate that such aliasing of it is permitted.
Mappings like shared libs and executables would not have this bit,
only libffi's closure buffer.

(Attackers who can call mmap to obtain a writable mapping could
arguably perpetrate the same workaround as libffi: write to a file
and then read+exec map it. So why worry about this too much.)

Summary:

   /* new flags + kernel support */
   #define MAP_ALIAS        ...
   #define PROT_ALIAS_OK ...

   void *closures = mmap(NULL, len,
                         PROT_READ | PROT_EXEC | PROT_ALIAS_OK,
                         MAP_ANONYMOUS | MAP_PRIVATE, -1, 0);

   void *write_closures = mmap(closures, len,
                               PROT_WRITE,
                               MAP_ALIAS | MAP_PRIVATE, -1, 0);


Write closures through write_closures pointer, execute via
closures pointer.

The kernel code for MAP_ALIAS has to ensure that fork
observes this linkage. That is tricky. The child process gets
its own copy of this memory, and the two aliased views of it.
The views cannot just be subject to independent COW because
their aliasing relationship will break.

One more detail: mprotect should disallow PROT_ALIAS_OK.
Only the original mmap must be able to specify PROT_ALIAS_OK,
which is then a mapping's immutable flag.