[csw-maintainers] Symbol versioning for openssl ?
Yann Rouillard
yann at pleiades.fr.eu.org
Sun Jul 22 03:03:15 CEST 2012
Hi everyone,
I am trying to enable symbol versioning with openssl because I think it
would be a better solution to avoid in the future the current difficulties
we are facing with the openssl migration.
However I have some difficulties to have it working and I am not yet sure
it will effectively solves the problem.
I thought that, with symbol versoning, libraries and program linked with
libssl0.9.8 or libssl1.0.0 would always be linked with the correct library
even in runtime dual-linking situation, because the linked would detect
that the one library wants the symbol from the 0.9.8 library only and the
other one wants the same symbol but from the 1.0.0 library.
It doesn't seem to work exactly as I expected, I still some additional
tests to do to understand but I would definitely welcome any light on this
subject.
I compiled a version of openssl for Solaris >=10 x86 in my experimental
repository for those who would like to try:
pkgutil -t http://buildfarm.opencsw.org/opencsw/experimental/yann-i
libssl1_0_0 libssl_dev openssl_utils
Here are some information I've found:
http://docs.oracle.com/cd/E23824_01/html/821-1602/solarisabi-6.html#solarisabi-8
http://docs.oracle.com/cd/E19082-01/819-0690/chapter5-84101/index.html
Here is the details of the tests I've done.
- I first tried to test if a binary linked with the symbol versioned libssl
would work with the unversioned one. I expected that it would'nt work.
To test that, I kept the openssl binary linked with the symbols versioned
libssl and downgraded libssl to the unversioned one.
After that, ldd clearly showed that the installed library was lacking the
good version of the library.
# ldd /opt/csw/bin/openssl
libssl.so.1.0.0 => /opt/csw/lib/i386/libssl.so.1.0.0
libssl.so.1.0.0 (OPENSSL_1.0.1) => (version not found)
libcrypto.so.1.0.0 => /opt/csw/lib/i386/libcrypto.so.1.0.0
libcrypto.so.1.0.0 (OPENSSL_1.0.1) => (version not found)
[...]
but openssl still worked correctly !!
I was able to launch it, it works and with verbose linking information, I
clearly saw that ld.so linked openssl with libssl, although it clearly
noticed that it wanted the version OPENSSL_1.0.1 of the library.
# LD_DEBUG=all LD_BIND_NOW=1 /opt/csw/bin/openssl
[...]
01133: version needed processing: file=/opt/csw/bin/openssl
01133: file version
01133: libssl.so.1.0.0 OPENSSL_1.0.1
[...]
01133: binding file=/opt/csw/bin/openssl to
file=/opt/csw/lib/i386/libssl.so.1.0.0: symbol 'i2d_SSL_SESSION'
[...]
and the libssl definitely didn't have the OPENSSL_1.0.1 version
# pvs -s /opt/csw/lib/libssl.so.1.0.0
(nothing)
- I tried then to test if binary linked with the unversioned library would
work with the versioned one.
I installed openssl_utils from the unstable repository and installed the
libssl1-0-0 package from my experimental repository.
Again openssl worked perfectly, and didn't complain at all, although libssl
did implement the versioned symbols:
# pvs -s /opt/csw/lib/libssl.so.1.0.0
[...]
libssl.so.1.0.0:
_GLOBAL_OFFSET_TABLE_;
_etext;
_DYNAMIC;
_edata;
_end;
_PROCEDURE_LINKAGE_TABLE_;
OPENSSL_1.0.0:
SSL_get_shared_ciphers;
SSL_set_bio;
[...]
OPENSSL_1.0.1:
SSL_CTX_set_srp_client_pwd_callback;
[...]
That's less a problem here, because that would ease the migration to a
libssl with symbol versioning and allow third binaries to use our libssl
library even if they didn't compile against it.
But I still don't understand how this it is supposed to work and I am not
quite sure it will prevent an library linked with libsslX to link with
libsslX+1 at runtime.
It seems the linker consider that an unversioned symbol can be linked to
any versioned one.
I will try to compile a libssl0.9.8 with symbol versioning to really test
if this would help during a library migration.
Yann
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opencsw.org/pipermail/maintainers/attachments/20120722/94030da5/attachment.html>
More information about the maintainers
mailing list