1

Many discussions like this and this have warned us with examples that trying to dlopen a PIE could never be correct. The reasons are various: copy relocations, TLS, etc.

However, these problems can be circumvented if we loose the restriction. This question showed us compiling with fPIC can eliminate copy relocation, and TLS seems to work alright.

This brings up the question about how far we are from correctly dynamic loading a PIE. I agree with the idea again in link 1:

Bottom line: this was never designed to work, and you just happened to not step on many of the land-mines, so you thought it is working, when in fact you were exercising undefined behavior.

But I'm more interesting about WHY we could not do that, instead of another failing example.

More specifically, users could write their own runtime dynamic linker as this comment suggest, which could make some strong assumptions or compromises just for this purpose. Yet this requires extremely broad knowledge on compiling, linking and loading, some of which are known to be poorly documented.

So again, how do users correctly dynamic load PIEs, or at least how can they try to find a way to do that(or not to do that)?

yhdang
  • 169
  • 8

1 Answers1

0

But I'm more interesting about WHY we could not do that, instead of another failing example.

Because the designers of GLIBC didn't intend to allow for this to happen and don't consider this to be a valid use case.

More specifically, users could write their own runtime dynamic linker

Absolutely. You are free to design your own libc and the dynamic loader to allow for this use case. That requirement will add some complexity, but there is no fundamental reason it can't be done.

You may also find an existing alternate libc implementation which doesn't have this restriction (either because it has been designed in, or because the designers forgot to enforce it, as was the case with GLIBC before this patch).

how do users correctly dynamic load PIEs

They don't.

how can they try to find a way to do that(or not to do that)?

The usual solution is to "not do that", and in fact the need to "do that" seems to be very esoteric.

Why do you need to dlopen a PIE executable in the first place?

Employed Russian
  • 199,314
  • 34
  • 295
  • 362
  • *Why do you need to dlopen a PIE executable in the first place?* I want to have some existing PIEs working as modules for my program, e.g., a web browser that needs plugins. I have no access to the source of these PIEs, only binaries, so recompiling is not an option. Running them in separate processes works, but I also want it to be as fast as possible, so keeping things inside single process might be better. – yhdang Dec 20 '21 at 02:52
  • *How do users correctly dynamic load PIEs? They don't* I know that this is an edge case and would be never used widely. So it makes sense to me that `libc` does not support it. That's why I use *dynamic load* instead of `dlopen`. But in the BZ page from original question, the developer says "it breaks ABI", so I don't know if there is eventually a way to do this. – yhdang Dec 20 '21 at 03:00