Re: [PATCH 2/2] dlfcn,elf: implement dlmem() function [BZ #11767]

[Florian Weimer <fweimer@redhat.com>]

* Stas Sergeev via Libc-alpha:

> This patch adds the following function:
> void *dlmem(const char *buffer, size_t size, int flags);
>
> It is the same as dlopen() but allows to dynamic-link solibs from
> the memory buffer, rather than from a file as dlopen() does.
>
> "buffer" arg is the pointer to the solib image in memory.
> "size" is the solib image size. Must be smaller-or-equal to the
> actual buffer size.
> "flags" is the same flags argument used in dlopen().
>
> The idea behind the implementation is very simple: where the
> dlopen() would mmap() the file, dlmem() does anonymous
> mmap()+memcpy().
> Unfortunately the glibc code was too bound to the file reads,
> so the patch looks bigger than it should. Some refactorings
> were needed to avoid big copy/pasts and code duplications.
> In particular, _dl_map_object_from_fd() was split and now calls
> 2 functions that are also called from __dl_map_object_from_mem().
> The same treatment was applied to open_verify() - the part that
> can be shared, was split into do_open_verify().
>
> This patch adds a test-case named tst-dlmem.
> The test-suite was run on x86_64/64 and showed no regressions.

On the Google branches, there is somewhat similar functionality, in the
form of dlopen_with_offset.  Their approach avoids some ambiguity
inherent to to the dlmem interface, mostly around whose responsibility
is it to set up the page protections.

Your patch seems to allow the creation of fully unnamed link maps
(especially if the shared object being loaded does not come with
DT_SONAME).  I think we need to discuss the consequences of that.  This
feature could be independently useful to some applications, to the
extent that they would use dlmem just for that purposes (even for files
that are stored on disk).

The test case could be extended to cover some failure cases, like a
purposefully misaligned buffer containing a valid ELF object.  Or the
interaction with auditing.

Thanks,
Florian