0

We face an issue with our shared library linked statically with OpenSSL. The library is used in Apache HTTP Server.Although we have compiled our shared library statically with OpenSSL, it was using system OpenSSL library path, which the web server was using for https (web server SSL). We could reverse this behavior and force the https to use our OpenSSL library by setting LD_LIBRARY_PATH. But this is not what we want. We want Apache HTTP Server to use its own OpenSSL library and our SSL module (loaded on Apache) to use its own version of OpenSSL libraries. This we could not achieve and hence we followed the compiler option mentioned in the below link to control the visibility of symbols hoping it may fix the problem. (we are not doing wrapper shared library)

https://wiki.openssl.org/index.php/Android#Wrapper_Shared_Objects

g++ SSlModule.cpp -fPIC -shared -I/usr/local/ssl/include -fvisibility=hidden -Wl,--exclude-libs,ALL \
-Wl,-Bstatic -lcrypto -lssl -L/usr/local/ssl/lib -o SSLModule.so -Wl,-Bdynamic

The new shared library gives the error “undefined symbol OPENSSL_sk_num” while starting Apache HTTP Server. Can someone suggest any solution to our problem?

SOLUTION:

Drepper's paper pointed by Basile Starynkevitch was quite useful. Finally we have successfully compiled our module statically linked to OpenSSL

Detailing the main steps.

1)Used -Wl,-z,defs option. Then it was reporting many errors. Hence I have used a Makefile. Our module actually contained more than just a .cpp file

2)Used linker option --exclude-libs and excluded libssl.a and libcrypto.a from the export

3)Used -fvisbility=hidden flag in make file so that some of the symbols were made hidden

4)Used attribute ((visibility ("default"))) for exported functions The output shared library was still exporting two symbols for which it was reading from the global scope

5)Statically linked against OpenSSL

As a special use case we have used the flag RTLD_NOW| RTLD_DEEPBIND(second argument to dlopen) so that our library reads from local scope. RTLD_DEEPBIND flag is to be used in rare use cases as per Drepper's post. So we will not include this in our general solution to all customers.

HoldOffHunger
  • 18,769
  • 10
  • 104
  • 133
George Thomas
  • 67
  • 1
  • 12

1 Answers1

0

We face an issue with our shared library linked statically with OpenSSL.

This static linking into a shared library a bad idea on Linux, both technically and perhaps even legally. But I am not a lawyer. Read Program Library HowTO and Linkers and Loaders

For the technical reasons, understand that a shared library on Linux practically needs to be position-independent-code (PIC) because of ASLR. See also vdso(7), execve(2), syscalls(2), credentials(7). Every Linux program except /sbin/init (and a few others related to systemd and udev or modprobe) is started by execve which often would run ld.so(8).

Drepper's paper How to write shared libraries explains that in details.

Read also Advanced Linux Programming and see kernelnewbies.org

Your user would be annoyed too. Use strace(1) and ltrace(1) and gdb(1) to understand what is going on. See also this draft report (explaining interesting facts about GCC compilers).

And some open source licenses discourage static linking into a shared library. Check with your lawyer and perhaps with the FSF, and the copyright owners of OpenSSL.

At the very least, recompile OpenSSL from its source code into PIC code and object files.

NB: Android is sort-of a Linux system. It runs a Linux kernel.

Basile Starynkevitch
  • 223,805
  • 18
  • 296
  • 547
  • Let me clarify about the problem. OpenSSL supports compiling its source code statically or dynamically. But when we link our shared library statically linked to OpenSSL we do not see a difference in behavior. It still needs libCrypto* and libSSL* shared libraries of OpenSSL for execution. We wanted to avoid dependency on libCrypto* and libSSL* shared libraries. For this reason we have compiled our module with -fvisibility=hidden, but faces the initially mentioned error on loading the module in Apache HTTP Server. Any suggestions? – George Thomas Jun 12 '20 at 13:40
  • Can someone suggest whether this link https://wiki.openssl.org/index.php/Compilation_and_Installation#Using_RPATHs may help to resolve the problem. I think it suggests on building OpenSSL dynamically and the shared libraries linked to this also should use rpath. If this is the correct way can someone give an example on how rpath can be specified in the shared library make file (that will get linked dynamically to OpenSSL libraries) – George Thomas Jun 18 '20 at 09:49
  • I leave you to experiment things. – Basile Starynkevitch Jun 19 '20 at 06:17
  • We have compiled with -rpath and not using --enable-new-dtags option. So our OpenSSL dependencies were getting loaded. But this was not satisfying our requirement. Finally we had managed to successfully statically link with OpenSSL – George Thomas Jun 24 '20 at 16:45