On 28-09-2010 06:39, Vivek Madani wrote:
<Clipped earlier communication>
What OS is this running on? That error can be caused by a DLL being loaded to
an address that is already in use under Windows and relocation would
invalidate the signature.
You can work around that by specifying an alternative load address when the
DLL is compiled.
This is Win2K3 on a virtual machine. I thought about the load address
and is looking through ProcessExplorer to see where the conflict is.
Will try a recompile.
One more query: Shouldn't fips_test_suite.exe report failure as well?
That passes without any issues.
Sorry for fragmenting my queries. Just figured out that there is
another DLL loaded at 0xFAF0000 which occupies 0x44000 bytes. So I
guess that explains why libeay32.dll is not getting loaded at
0xFB00000.
Just curious, what was the conflicting dll?
> Now my query is if I recompile it with a different base
address, isn't there a rare possibility that I might see this issue in
some other environment?
Unfortunately yes, this is a weakness of the design of the old FIPS
module, which I hope the OpenSSL developers will change when the
get around to creating a new Suite B compliant FIPS module for OpenSSL 1.x.
Anyway I can be sure that this will work
always?
No, see above.
One additional thing you can do is to link the DLL with the Windows
linker switch "/FIXED" . This tells Windows that it must never
relocate this DLL (and in fact removes the data to do so), causing
Windows to simply refuse to load the DLL at the wrong address, with
a more appropriate error code than "self-test failed" .
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List openssl-users@openssl.org
Automated List Manager majord...@openssl.org
