This is the mail archive of the glibc-bugs@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[Bug dynamic-link/11767] RFE: dlopen of in-memory ET_DYN or ET_EXEC object


http://sourceware.org/bugzilla/show_bug.cgi?id=11767

--- Comment #4 from Paul Pluzhnikov <ppluzhnikov at google dot com> 2012-07-18 14:16:59 UTC ---
(In reply to comment #3)
> If you want to embed the .so's in the main program binary, why are you not just
> static linking them to begin with?

How is static linking useful when managing modules created at runtime?

Various JITters do that. Usually they don't generate full ELF, but then GDB
doesn't know how to debug them. 

> With that said, I really question the validity of this feature request. Using
> the .so in-place from data embedded in the main program would only be possible
> if it's page-aligned, and would be a security risk anyway since the whole .so
> image would be writable, thus requiring write+exec permission on the pages that
> most security-enhanced systems don't even allow these days. Thus you'd have to
> make a copy of the whole .so image, and the copy would have to be anonymous
> memory that consumes actual physical runtime memory and commit charge, rather
> than being a file-backed mapping. In other words, it wastes a good deal more
> memory than loading a .so from a separate file.

You appear to be making a whole lot of unwarranted assumptions in your
argument.

Think UPX: it has the main executable (and could have shared libraries)
compressed. It decompresses them to memory, and can arrange for them to be
properly aligned, and mprotect()ed RO. It is wasteful to require UPX to write
such images to disk only so they can be dlopen()ed and immediately unlink()ed.

-- 
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]