> 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.
Why libcrypto.a is built as a PIC, then turned into a shared library
is totally beyond me. However, I see where you are heading. ;-)
> > 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?
Please note FreeBSD has OpenSSL in the base and we have our own custom
Makefiles for many reasons, e.g., cross-compilation, FreeBSD build
tunables, etc. Specifically, libcrypto.a is not built as a PIC and
libcrypto.so is directly built from source files without need for
libcrypto.a.
> > 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.
For fipscanister.o and stuff, it builds fine without a complaint but
it crashes later on, i.e., when .init section is executed. Please
note we are not supposed to link fipscanister.o directly but fipsld
must be used, instead of cc/ld. If "-Bsymbolic" was absolutely
required for FIPS-capable binary build, it had to be passed down from
fipsld, IMHO.
> > 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.
Ah, I mis-understood that; please ignore the stable patch. And,
thanks for the clarification!
> 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.
It builds and works fine now *without* "-Bsymbolic" from FreeBSD base.
FYI, my FreeBSD patchset is here:
http://people.freebsd.org/~jkim/openssl-head3.diff
Please note FreeBSD HEAD is still at 0.9.8q.
Thanks!
Jung-uk Kim
______________________________________________________________________
OpenSSL Project http://www.openssl.org
Development Mailing List [email protected]
Automated List Manager [email protected]
