Re: [PATCH v9 0/13] implement dlmem() function

[Adhemerval Zanella Netto <adhemerval.zanella@linaro.org>]

On 18/03/23 13:50, Stas Sergeev via Libc-alpha wrote:
> Changes in v9:
> - use "zero-copy" machinery instead of memcpy(). It works on linux 5.13
>   and newer, falling back to memcpy() otherwise. Suggested by Florian Weimer.
> - implement fdlopen() using the above functionality. It is in a new test
>   tst-dlmem-fdlopen. Suggested by Carlos O'Donell.
> - add DLMEM_DONTREPLACE flag that doesn't replace the backing-store mapping.
>   It switches back to memcpy(). Test-case is called tst-dlmem-shm.

Hi Stas,

This discussion has been dragging without much conclusion while you have sent
multiple iterations of the same proposal without addressing the initial issues
Carlos, Jonathan, and myself have raised.

I will not focus on your specific usercase since it is quite singular and I 
think will not be applicable to a libc interface (mapping a VM memory with
different bit size and gluing all together should be an application domain
instead of bleeding out the interface to the libc).

Jonathan already summarized the main issue with dlmem:

  - dlmem() seems to to expect the user to parse the program headers and mmap()
  the binary as required. That requires the application to re-implement a core,
  delicate piece of ld.so... and do so correctly. From an API design perspective,
  that seems like a very poor choice of abstraction.

As well Carlos:

  * No guarantee that the memory that is loaded meets the preconditions for the
  dynamic loader and application uses.

And this alone seems to me that this interface is not easily composable and 
adds a lot of corner cases if the user does not provide an expected ELF image.
This is in par of what Carlos has raised [1] and IMHO you have not addresses the
issues, since you have focused on how this interface applies to your specific
problem instead of see who it fits as a generic libc interface (I will let
Carlos comment further).

As a generic interface I also don't see how this would really fit, it means
that process need to map a memory segment that was generated either through
a JIT or through an external process that can not provide a named file access
(due security limitation).  For these a fdlopen similar to BSD makes more
sense: for former memfd_create can be used, while for later either shm_open 
or passing the fd through unix sockets.

So I don't think dlmem really fits on glibc, although I might take a loot
on the internal code refactoring. I am ccing Rich Felker, creator of musl
libc, since he might have some additional insights whether this interface
make sense or not (and he usually have good ones).

[1] https://sourceware.org/pipermail/libc-alpha/2023-February/145735.html