Using openssl-1.0.1c, cross-compiling for x86 netbsd target.
When libcrypto.so is linked up, I get warnings due to the
OPENSSL_cpuid_setup call in x86cpuid.S:
../lib/gcc/i386--netbsdelf/4.1.3/../../../../i386--netbsdelf/bin/ld: warning:
dynamic relocation in readonly section `OPENSSL_cpuid_setup'
../lib/gcc/i386--netbsdelf/4.1.3/../../../../i386--netbsdelf/bin/ld: warning:
creating a DT_TEXTREL in a shared object.
The problem was discussed in x86_64 context and "official" answer is
"adhere to -Wl,-Bsymbolic". Not only that it's better for performahnce,
it's more than appropriate in fips module in shared library context.
Because it ensures that calls made from fips module can't be overridden
by another shared library. There is additional provision in x86_64 code,
namely .hidden directives, which could be adopted even for x86 build.
But in fips context modifications are not option, but you can use
-Wl,-Bsymbolic when linking your libcrypto.so. There is another
possibility, passing -Wl,--version-script=foo.ld that reads
{
local:
OPENSSL_cpuid_setup; OPENSSL_ia32cap_P;
};
It should be noted that all of the mentioned workarounds result in
binary code *identical* to one generated with warning, just without
warning. This means that the binary with warning is actually the desired
outcome.
So my questions:
1. For x86 platforms, do other users/builders encounter this warning
when building openssl-1.0.1c? (Or is it dependent on netbsd target, or
the gcc version I use)?
Warning has not been seen in x86 context, only in x86_64 context.
2. If so, have others simply ignored the warnings, or worked to resolve
them?
3. Is the change I made for openssl x86cpuid.S above an acceptable way
to resolve the warnings?
4. For fips-2.0 on x86 platforms, do other users/builders encounter the
fips_openssl_cpuid_setup warning when building fips-capable libcrypto.so?
I reckon that above answers these questions.
5. If I have to modify the perl script in the fips module to eliminate
the warnings on building fips-capable libcrypto.so, will that
modification still qualify for a Change Letter validation?
I bet perl script modification would require Change Letter, but
additional linker argument to 1.0.1 being linked with fips module would not.
______________________________________________________________________
OpenSSL Project http://www.openssl.org
Development Mailing List [email protected]
Automated List Manager [email protected]