public inbox for libc-help@sourceware.org
 help / color / mirror / Atom feed
* The correctness of dlopen-ing a PIE executable
@ 2021-05-03 16:20 Fengkai Sun
  0 siblings, 0 replies; only message in thread
From: Fengkai Sun @ 2021-05-03 16:20 UTC (permalink / raw)
  To: libc-help

Hi list,

I'm very interested in the idea of dynamically loading a PIE
executable using dlopen, and I found a patch at:
https://sourceware.org/bugzilla/show_bug.cgi?id=11754

However, as the comment(
https://sourceware.org/bugzilla/show_bug.cgi?id=11754#c13) below suggests,
this is a bad idea. So glibc explicitly forbids it in dl-load.c.

But in this question:
https://stackoverflow.com/questions/64659713/why-does-dynamically-loading-of-pies-no-longer-work-in-glibc,
the author shows that:

* recompile the executable using -fPIC, which eliminates relocation type
R_X86_64_COPY, will fix the bug in
https://sourceware.org/bugzilla/show_bug.cgi?id=11754#c15
* constructors, relocations, and thread local variables seem to work OK

I know that the reasons the author above listed are probably not
exhaustive, so I want to make it clear that is there any irrecoverable
problem that prevents dlopen to load PIE executable correctly?(suppose we
force the executable enable -fPIC )
If so, how will a modified loader manage to solve that, as mentioned in
https://sourceware.org/bugzilla/show_bug.cgi?id=11754#c16  ?

Thank you very much.


Best,
Fengkai

^ permalink raw reply	[flat|nested] only message in thread

only message in thread, other threads:[~2021-05-03 16:20 UTC | newest]

Thread overview: (only message) (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2021-05-03 16:20 The correctness of dlopen-ing a PIE executable Fengkai Sun

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).