Dynamic Linker: Exposing static symbols at runtime

Dynamic Linker: Exposing static symbols at runtime

[Harley Paterson]

Hello,

I'm doing some research on dynamic software updating recently. I've found it would be very helpful to expose static symbols to running program, much like `dlopen`, `dlsym`, and friends expose dynamic symbols to running programs via the `dlfcn.h` header.

Is anyone able to provide insight into what work is required to get the `ld-linux.so` to read the static symbol stable, and expose symbols to processes via an API?

Would the `glibc` community, additionally, be interested in patch with this functionality when or if I implemented it? I can't immediately think of any use cases except my own, however I'm quite willing to contribute this functionality back if the community wants it.

In my use case, my patching software sits between the loader and the user's target program. When the user issues a request to patch software, along with a target binary, the patcher attempts find symbols which have changed between the loaded version and the updated verion, loads the new versions into memory, and patches up requests - either by writing to the PLT, or inserting long jumps into the existing functions. I currently anticipate writing an ELF parser in my patching software to get symbols in the two binaries, although there are some compilations such as relations and base addresses which make me suspect this functionality would be best placed in the dynamic linker, which is awear of the load-time relocations.

I appreciate any insight you can provide,



H Paterson.

Re: Dynamic Linker: Exposing static symbols at runtime

[Florian Weimer]

* Harley Paterson via Libc-alpha:

> I'm doing some research on dynamic software updating recently. I've
> found it would be very helpful to expose static symbols to running
> program, much like `dlopen`, `dlsym`, and friends expose dynamic
> symbols to running programs via the `dlfcn.h` header.
>
> Is anyone able to provide insight into what work is required to get
> the `ld-linux.so` to read the static symbol stable, and expose symbols
> to processes via an API?

In general, the static symbol table is not mapped into memory because it
is not located in an allocated section.  So the dynamic loader cannot
provide this data any more easily than a separate library could: it
would have to load it from disk as a first step, too.  This suggests to
me that glibc integration is not really needed.

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