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

[stsp <stsp2@yandex.ru>]

13.02.2023 18:45, Florian Weimer пишет:
> * Stas Sergeev via Libc-alpha:
>
> On the Google branches, there is somewhat similar functionality, in the
> form of dlopen_with_offset.

I've seen its mentioning here:
https://sourceware.org/bugzilla/show_bug.cgi?id=11767
But the attachment that is supposed to
be that patch, is
"attachment-3251-0.html (112 bytes, text/html)",
and if you click on it, you'll see something
completely silly.
So I thought that patch is a vaporware.

And in any case, I don't have an fd at all.
Maybe if they implemented dlopen_fstream(),
then I could use it with fopencookie.
But overall I need dlmem() w/o any fd.


>    Their approach avoids some ambiguity
> inherent to to the dlmem interface, mostly around whose responsibility
> is it to set up the page protections.

You probably mean the ambiguity of _their_
dlmem() interface. They discussed it entirely
differently: they wanted dlmem() to work on
a user's buffer.
My approach is very simple: dlmem() does
any mapping and protection, and memcpy()
from the original buffer. Then user does
munmap() of his buf.

dlmem() to user's buffer will be added later.
I am going to add it via an LD_AUDIT extension
that tells you the size and gets back the
address where you want it to mmap the solib.
So while I want to cover all their ideas, the
implementation is very simple and no
ambiguity should arise from it.


> 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).

Yes, I actually thought of a possibility to
set a name... Although this can be done
later, by someone who needs it.
Probably that will require dlmem2() with
one more argument.

> The test case could be extended to cover some failure cases, like a
> purposefully misaligned buffer containing a valid ELF object.

For my impl its not a failure case, simply
because of memcpy().


>    Or the
> interaction with auditing.
I was planning that for the next patch-set
where I will be covering the user's address.
But I'll see what can be added to current one.