First of all, let's ask ourselves how come vanilla openssl build doesn't
fail? I mean download, unpack, './config shared' and 'make'... The
answer is because libcrypto.so is linked with -Bsymbolic. Want to get
rid of the error in your builds? Add -Bsymbolic too... It's more than
appropriate in cases when you embed libcrypto.a into another shared
library, which [normally] is not meant to export OpenSSL symbols. By
doing so, you avoid symbol table cross contamination and so to say
imprison openssl in your shared library. Regardless outcome of this
discussion I'd recommend [at least Rob] to consider doing so.
> I am a FreeBSD developer and I was bitten by this bug on FreeBSD/amd64
> -CURRENT as well. Probably it was silently ignored by old binutils
> but it fails the same way now as Linux distros do.
Now let's ask ourselves what was going on when it didn't complain? I.e.
in cases when -Bsymbolic was not used. Was it emitting
non-position-independent code? No. It was short-circuiting reference to
symbol within same shared object, simply avoiding global table. It was
kind of doing -Bsymbolic thing just for that particular symbol. Why was
it error?
> Most importantly,
> FIPS canister built with ASM also fails as it contains aes-x86_64.o
> and x86_64cpuid.o. The only way to build usable FIPS canister is
> building it without ASM, i.e., "./config fipscanisterbuild no-asm &&
> make".
I can't confirm this. I.e. if I './config fipscanisterbuild' on FreeBSD
8.2, it builds without errors. As mentioned above, because even on
FreeBSD pristine openssl tar-ball passes -Bsymbolic to linker. Or do you
mean you get failure later on, when you link with fipscanister.o with
own link rules? BTW, linking fipscanister.o with -Bsymbolic is also
*more than appropriate*, because it assures that execution flow is
contained within the module.
> Although the analysis seems correct (nice catch!), the actual patch
> does not seem right to me, i.e., OPENSSL_ia32cap_P was NOT a pointer
> on stable branches. Even for dev branches, where it IS really a
> pointer, it only loaded the bottom half. Because of this problem,
> the generated executable actually crashed. My patches are attached
> here.
The conclusion that OPENSSL_ia32cap_P needs different treatment in
assembler in stable and development branches is incorrect. While it's
true that it's a *C* variable in stable and 2-element *C* array in
development, *from assembler viewpoint* there is *no* difference.
Because in assembler OPENSSL_ia32cap_P symbol is a reference in either
case. Generate assembler listings for 'extern int i; void *foo() {
return &i; }' and 'extern int i[]; void *foo() { return i; }' and compare.
Anyway. As already implied, it's considered favorable to "short-circuit"
references within shared module [they don't have to be resolved through
GOT], so the "official" solution to the problem is
http://cvs.openssl.org/chngview?cn=20836. A.
______________________________________________________________________
OpenSSL Project http://www.openssl.org
Development Mailing List [email protected]
Automated List Manager [email protected]
