>>> [EMAIL PROTECTED]:~$ 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. > > -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
... meaning that -Bsymbolic *ensures* that cryptographically significant control flow is contained within the library. Symbol versioning allows to avoid conflicts, but it does not *ensure* that internal symbol can't be overridden and that control flow doesn't leave the library boundaries, not in uncontrollable manner. In other words, that's the way we like it. Even if we used symbol versioning (well, probably we should and will at some point), we would still use -Bsymbolic. > -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. While not having -Bsymbolic effectively makes all calls indirect, which negatively affects run-time performance... > 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. Yes, and exactly this is considered appropriate in context of cryptographic library. > 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. Yes, we probably should do just that at some point. But we would still stick to -Bsymbolic:-) A. ______________________________________________________________________ OpenSSL Project http://www.openssl.org Development Mailing List [email protected] Automated List Manager [EMAIL PROTECTED]
