RE: [External] Support for -fvisibility=hidden in openssl 3.0

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Answering myself here. It appears this is pretty logical. Openssl 3.0 has a “legacy” provider which is normally compiled as a separate legacy.so module which is loaded on demand at run time. Now, when compiled with -fvisibility=hidden, this does not work because neither side can see each other’s symbols.

 

The solution appears to be simple: one needs to pass no-module option to the openssl config, which causes the legacy provider  to be linked directly into libcrypto.a.

 

Another solution would probably be to convince the aws-cpp-sdk library to not to try to load the legacy provider in the first place. I see this is done inside a conditional compilation block (#ifdef S2N_LIBCRYPTO_SUPPORTS_EVP_RC4), so should be somehow configurable as well.

 

Cheers

Paavo

 

From: openssl-users <openssl-users-bounces@xxxxxxxxxxx> On Behalf Of Helde, Paavo
Sent: neljapäev, 10. november 2022 16:45
To: openssl-users@xxxxxxxxxxx
Subject: [External] Support for -fvisibility=hidden in openssl 3.0

 

 

We have a Linux application which can load a lot of different .so modules at runtime, which in turn might be contain various third-party libraries. In the past we have seen the problems that there might appear different binarily incompatible openssl versions in the process memory, which might get mixed up and cause crashes or worse. The worst offender was libpython which can install and load its own modules on fly, with totally uncontrollable openssl versions in them.

 

We attempted to fight with this by compiling static openssl libraries with -fvisibility=hidden and linking our own .so-s against it. This ought to hide the symbols from Python at least. It looks like this actually worked with openssl-1.1.

 

Alas, now we are switching over to openssl-3.0 (the fresh 3.0.7) and it looks like this approach does not work anymore. We are getting initialization errors, I think from OSSL_PROVIDER_load(“legacy”) or such.

 

s2n_init() failed: 402653268 (Failed to load or unload an openssl provider)

Fatal error condition occurred in /srv/paavo/DataAnalysis/Acapella/trunk/Production/Intermediates/ThirdParty/src/aws-sdk-cpp/crt/aws-crt-cpp/crt/aws-c-io/source/s2n/s2n_tls_channel_handler.c:197: 0 && "s2n_init() failed"

Exiting Application

No call stack information available

Aborted (core dumped)

 

Removing the -fvisibility=hidden flag from openssl compilation gets rid of this problem, but I’m afraid this may cause conflicts with python again.

 

So my question is should this usage work, and if so, how to get it working?

 

TIA

Paavo


[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Security]     [Bugtraq]     [Linux]     [Linux OMAP]     [Linux MIPS]     [ECOS]     [Asterisk Internet PBX]     [Linux API]

  Powered by Linux