On Sat, Oct 27, 2007 at 08:58:59PM +0200, Andy Polyakov via RT wrote:
> > Double-checking yields the following buried between 0x0013xxxx relocs :
> >
> > sjv@mlejnas:~$ readelf -r /usr/src/openssl-0.9.8e/i686/cmov/libcrypto.so.0.9.8
> > [...]
> > 0006354c 000ce102 R_386_PC32 00062630 DES_encrypt2
> > ...
> > 0006bd93 000c3e02 R_386_PC32 0006b820 BF_decrypt
> > [...]
> >
> > So it seems there are indeed relocations in the .text section

>
> The problem appears to be Debian specific. According to diff found at
> http://packages.qa.debian.org/o/openssl.html they remove -Bsymbolic from
> linker command line. This option takes care of relocations in generic
> openssl source available from ftp://ftp.openssl.org/source/. If Debian
> insists on removing this option, then formally they are responsible for
> resolving this relocations:-) I'm ready to listen to reasons why Debian
> considers -Bsymbolic inappropriate, but I want to point out that our
> goal is to target wide range of OSes, not some particular Linux
> distribution. A.


-Bsymbolic changes the order in which symbols are looked up so that it
takes the one from the local library, and not the first one and does
not follow the normal order taking by the dynamic linker. The main
reason this option exist is so that different libraries can have the
same symbol name yet use their own version, and something that links to
both of those still works. One example where you run into problems is
for instance being (inderctly) linked to 2 different versions of
openssl, like 0.9.7 and 0.9.8.

There is an other option that the linker provides that allows you to
deal with this type of problems and that's symbol versioning. With that
you say it's that symbol with that version. Where the version could
then be something like OPENSSL_0.9.8. Programs or other libraries
linked to the library will then know which version they need, and call
the right one.

-Bsymbolic has some side effects. One of them is that the dynamic linker
needs to create a special symbol table for such libraries and makes
symbol lookup slower. An other is that function calls to a function
in the same library can be resolved by the static linker so that you
don't end up with a (text) relocation for that. An other effect of
it is that you can't overwrite a function when using something as
LD_PRELOAD.

One of the other things you can do with symbol versioning is control
which symbols gets exported. Now every function and variable that
isn't static is exported. With symbol versioning you can provide
a list of symbols that need to be exported. We even already keep
a list of functions that we say we need to export in util/ssleay.num,
so this can be used perfectly for that.

There are alot of things you can do with the symbol versioning, but it's
clearly not supported on all arches. But it's still a useful thing
on those that do have it.

In Debian we prefer to have libraries with symbol versioning since
it avoids alot of problems in case of transitions from one library
version to another. -Bsymbolic is not enough to avoid the problems.
A structure created with one version of the library can be passed to
an other, and things break. So we added symbol versioning to openssl.
As since we have symbol versioning, -Bsymbolic doesn't seem useful to
have.

So, we ended up with a few text relocations since I disabled -Bsymbolic.
The assembler all seems to be written for PIC, except for the function
calls. None of the function calls in the assembler code use the PLT.

I solved a few of them by making _x86_AES_decrypt a static function, so it
doesn't need a relocation. I've also set up %ebx to point to the GOT
when calling AES_set_encrypt_key, and then call AES_set_encrypt_key via
the PLT. I did the same thing for OPENSSL_cpuid_setup.

This has left me with the relocations in the des and bf assembler
versions. I didn't have time to look into them yet.


Kurt

__________________________________________________ ____________________
OpenSSL Project http://www.openssl.org
Development Mailing List openssl-dev@openssl.org
Automated List Manager majordomo@openssl.org