Finding two ABI-incompatible versions of my shared library loaded in the same program

I wrote a shared library with several incompatible versions. I changed SONAME, so they are called:

  • lib_mylib.so.1.0.0 (older library)
  • lib_mylib.so.2.0.0

Some functions exist only in mylib.so.1, others only in mylib.so.2, and many functions are common (but some of them have changed the number of arguments)

And I'm afraid that it is possible to link both versions of mylib in one application, for example, when the application itself is large and consists of many libraries. When the application is partially restored, the following situation may occur:

  • Application
  • app_lib1.so (was built with mylib.so.1 - the first version of my library)
  • app_lib2.so (was rebuilt using mylib.so.2 - second version)

I already saw the application with two versions loaded into it ( ldd tells both).

So, is it possible to add a verification code to mylib.so.2 to find that there are both versions of an already loaded library, and they have conflicting ABI / Interface. (I cannot change lib_mylib.so.1 to add something to it)

+6
source share
2 answers

You can change your version 2 library to allow some version 1 character ( dlsym(3) ) during initialization and detection failure.

Example:

 extern __attribute__((constructor)) void _version_check2() { if (dlsym(RTLD_DEFAULT, "version_1_function")) abort(); } 

A more elegant solution is to let the version 2 library mimic the behavior of version 1, but this introduces legacy code.

EDIT

To be proof in the future, you can also introduce a static version variable, and all function calls will check if it matches the current one. Then in future versions, you just need to change the value of this variable and crash when inconsistent.

EDIT 2

You can also call this function for each function of version 2, so that sooner or later when loading version 1 the application crashes.

+3
source

You can parse /proc/self/maps to get a list of downloadable objects.

+1
source

Source: https://habr.com/ru/post/955207/


All Articles