On 09/11/2018 02:35 PM, Viktor Dukhovni wrote:
On Tue, Sep 11, 2018 at 02:28:12PM -0400, Dennis Clarke wrote:
It sounds like a downstream ELF header nightmare.
Actually, it works just fine. You link with the variant library,
and it happily coexists with any dependencies you may have that in
turn depend on the system TLS library. The variant SONAME and
symbol versions provide all the requisite isolation. You only
pay the cost of customization for the handful of packages you
want to have running against the non-default libraries.
Mildly interesting in giving it a try. However I have 1.1.1 running and
tested fine on Solaris 10 sparc without any interferance from the system
provided ( ORacle? ) ssl bits. However I do have RUNPATH and RPATH set
to /usr/local/lib for everything I have built.
One thing I've not tested, is isolation from system SSL libraries
that don't employ symbol versions. Debian has been doing symbol
versions for a long time, so I never needed to worry about that.
And OpenSSL 1.1.0 has symbol versions on most platforms.
I would assume that Solaris also has symbol versions for OpenSSL
1.0.x, but if it does not and that's the system's SSL library, then
the variant build might not happily coexist with indirect dependencies
in other shared libraries, haven't tried that. Regardless, you're
no worse off than with the default SONAME and symbol versions.
The GNU ld manual makes direct reference to ye old Solaris 2.5 as a sort
of template for the format used.
https://sourceware.org/binutils/docs/ld/VERSION.html
but you won't find the section headers ( SHT_GNU_versym, SHT_GNU_verdef,
and SHT_GNU_verneed ) in an ELF file on Solaris but SUNW_version has
been around forever ( I think I saw it in 1994 ? ) :
# elfdump -devl /usr/local/bin/openssl
ELF Header
ei_magic: { 0x7f, E, L, F }
ei_class: ELFCLASS64 ei_data: ELFDATA2MSB
ei_osabi: ELFOSABI_SOLARIS ei_abiversion: EAV_SUNW_CURRENT
e_machine: EM_SPARCV9 e_version: EV_CURRENT
e_type: ET_EXEC
e_flags: [ EF_SPARCV9_TSO ]
e_entry: 0x100020200 e_ehsize: 64 e_shstrndx: 29
e_shoff: 0x194bd78 e_shentsize: 64 e_shnum: 31
e_phoff: 0x40 e_phentsize: 56 e_phnum: 5
Version Needed Section: .SUNW_version
index file version
[2] libssl.so.1.1 OPENSSL_1_1_0 [ INFO ]
[3] OPENSSL_1_1_1
[4] libcrypto.so.1.1 OPENSSL_1_1_0 [ INFO ]
[5] OPENSSL_1_1_1
[6] libsocket.so.1 SUNW_0.7
[7] librt.so.1 SUNW_1.2
[8] SUNW_1.1 [ INFO ]
[9] libpthread.so.1 SUNW_1.2
[10] SUNW_0.9 [ INFO ]
[11] libc.so.1 SUNW_1.21.2
[12] SUNW_1.1 [ INFO ]
[13] SUNW_0.7 [ INFO ]
Dynamic Section: .dynamic
index tag value
[0] NEEDED 0x86d5 libssl.so.1.1
[1] NEEDED 0x86ff libcrypto.so.1.1
[2] NEEDED 0x8710 libsocket.so.1
[3] NEEDED 0x8774 libnsl.so.1
[4] NEEDED 0x8780 libdl.so.1
[5] NEEDED 0x8728 librt.so.1
[6] NEEDED 0x8745 libpthread.so.1
[7] NEEDED 0x875e libc.so.1
[8] INIT 0x100904ff8
[9] FINI 0x100905008
[10] RUNPATH 0x878b /usr/local/lib
[11] RPATH 0x878b /usr/local/lib
[12] HASH 0x100000178
[13] STRTAB 0x10000e710
[14] STRSZ 0x899a
[15] SYMTAB 0x100003b08
[16] SYMENT 0x18
[17] CHECKSUM 0x9857
[18] VERNEED 0x1000170b0
[19] VERNEEDNUM 0x6
[20] PLTRELSZ 0x7e48
[21] PLTREL 0x7
[22] JMPREL 0x1000183b8
[23] RELA 0x100018028
[24] RELASZ 0x81d8
[25] RELAENT 0x18
[26] DEBUG 0
[27] FLAGS 0 0
[28] FLAGS_1 0 0
[29] SUNW_STRPAD 0x200
[30] SUNW_LDMACH 0x2b EM_SPARCV9
[31] PLTGOT 0x100a26700
[32-42] NULL 0
jupiter #
Anyways .. the whole mess started with Sun's versioning concepts and it
was Ulrich Drepper that did the first implementation in glibc 2.1 with
Eric Youngdale who also bolted in "symbol-level versioning with multiple
definitions of a symbol." :
https://www.akkadia.org/drepper/symbol-versioning
As for the sections that GNU ld type tools are looking for .. nope .. no
such things in ye Solaris implementation. I'll take a gander at FreeBSD
which does use the GNU tools.
Dennis
--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
