Is writing a dynamic linker/loader to load glibc a bad idea?

Is writing a dynamic linker/loader to load glibc a bad idea?

[Fengkai Sun]

Hi list,

Sorry in advance if this question is a bit unclear and confusing.

Recently I want to implement an ld.so myself, that is, a DSO that allows me
to load other DSOs into memory.

I've tried my best to finish all the steps that I discovered: loading
PT_LOAD segments with mmap, loading dependencies, relocating, and calling
DT_INIT and DT_INITARRAY in the right order.

It works all right when the DSO is simple, e.g. using a few printfs and
other libc functions. But it fails when I'm using some(not all) DSOs in the
real world.

Through some debugging, I found that the problem might be caused by some
initialized variables. So I tried this when doing relocation:

IF FIND_SYMBOL_IN_LIBC:
        void* handle = dlopen("libc.so.6", RTLD_LAZY);
        void* symbol_address = dlsym(handle, symbol_name);
        if(symbol_address)
                return symbol_address;

And it works fine.

So I think the bug is obvious: I missed out some parts when trying to load
libc as a dependency. But libc is huge, I'm not sure if it is a great idea
to do that all by myself -- currently I cannot find what is overlooked.

Any intuitive advice will be greatly appreciated.

Best,
Fengkai

Re: Is writing a dynamic linker/loader to load glibc a bad idea?

[Florian Weimer]

* Fengkai Sun via Libc-help:

> Sorry in advance if this question is a bit unclear and confusing.
>
> Recently I want to implement an ld.so myself, that is, a DSO that allows me
> to load other DSOs into memory.
>
> I've tried my best to finish all the steps that I discovered: loading
> PT_LOAD segments with mmap, loading dependencies, relocating, and calling
> DT_INIT and DT_INITARRAY in the right order.
>
> It works all right when the DSO is simple, e.g. using a few printfs and
> other libc functions. But it fails when I'm using some(not all) DSOs in the
> real world.

At present, this isn't really possible because among other things, the
dynamic loader needs to provide the _rtld_global and and _rtld_global_ro
variable to libc.so.6, and the layout of these variables changes fairly
rapidly.

glibc's ld.so also knows about unusal initialization requirements for
libc.so.6 (see __libc_early_init, _dl_var_init).

It may be interesting to come up with the absolut minimum set of ld.so
interfaces, and try to move the rest into libc.so.6, and then stabilize
the interface between the two.

But today, glibc's hooking mechanism for ld.so is the audit (LD_AUDIT)
interface, not replacing ld.so completely.

Thanks,
Florian
-- 
Red Hat GmbH, https://de.redhat.com/ , Registered seat: Grasbrunn,
Commercial register: Amtsgericht Muenchen, HRB 153243,
Managing Directors: Charles Cachera, Brian Klemm, Laurie Krebs, Michael O'Neill