On 01/04/2013 03:45 AM, Jeffrey Walton wrote: > Hi All, > > I'm wondering how the single pass linker affects symbol resolution. If > I specify: > > fipscanister.o libcrpyto.a > > the linker will resolve symbols preferring the cryptography from > fipscanister.o, then from libcrpyto.a. After encountering > fipscanister.o, there should be no unresolved cryptography functions > since fipscanister.o provides the validated cryptography. > > However, what happens if the linker encounters libcrypto.a first: > > libcrpyto.a fipscanister.o > > In this case, shouldn't the linker resolve cryptography symbols with > libcrypto.a, which means non-validated cryptography will be linked > into the final application?
Well, first off you would never link against both fipscanister.o and libcrypto.a at the same time. Either the libcrypto.a is from a "FIPS capable" OpenSSL build, in which case it *contains* fipscanister.o, or it isn't in which case you shouldn't be trying to reference fipscanister.o at all. However, there are no symbol conflicts, as can be seen from: nm -g fipscanister.o nm -g libcrypto.a Remember that the FIPS module and OpenSSL (whether "FIPS capable" or not) are separate software products. Much of the source code in the FIPS module is common to OpenSSL as well, but during the build process symbols are renamed to different values to avoid the symbol conflicts you're concerned about. Historical note: earlier FIPS modules, 1.2.x and earlier, tackled that problem differently. -Steve M. -- Steve Marquess OpenSSL Software Foundation, Inc. 1829 Mount Ephraim Road Adamstown, MD 21710 USA +1 877 673 6775 s/b +1 301 874 2571 direct [email protected] [email protected] ______________________________________________________________________ OpenSSL Project http://www.openssl.org User Support Mailing List [email protected] Automated List Manager [email protected]
