Re: FIPS linked as a shared library
I have not seen an answer to this mail. Wouldn't applying PIC accomplish the same thing? Thank you, -Pandit From: William A. Rowe Jr. wr...@rowe-clan.net To: openssl-users@openssl.org Cc: Kyle Hamilton aerow...@gmail.com Sent: Mon, January 18, 2010 6:20:11 PM Subject: Re: FIPS linked as a shared library On 1/18/2010 2:42 PM, Kyle Hamilton wrote: The way that the FIPS module verifies its signature is that it forces itself to load (via a pre-main() section) and then calculate the checksum of the image in-core. Probably the reason why you're running into issues is because of the fixup step of the dynamic linker. If you expect to use FIPS, you should link it as a hard dependency (also known as 'strict binding', as opposed to 'lazy binding') so that it can be loaded as early as possible, to minimize the chances of the linker needing to run fixups after application-code memory allocation. As you've found, the image in-core *must* match the original image in-core when the signature was generated, and the linker changes the pointers of where things are located when it has to. Wouldn't applying the PIC compiler flag across all .o's accomplish the same thing? __ OpenSSL Projecthttp://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
RE: FIPS linked as a shared library
Would you elaborate what is meant by 'strict binding' please. I have tried compiling with '-z now', I have tried RTLD_LAZY and RTLD_NOW as flags to dlopen and the env var LD_BIND_NOW also had no effect. I have reproduced the same issue of the shared lib Failing on both x86 and mips. Has anyone created and used a shared library? -Matt Bancroft -Original Message- From: owner-openssl-us...@openssl.org [mailto:owner-openssl-us...@openssl.org] On Behalf Of Kyle Hamilton Sent: 18 January 2010 20:43 To: openssl-users Subject: Re: FIPS linked as a shared library The way that the FIPS module verifies its signature is that it forces itself to load (via a pre-main() section) and then calculate the checksum of the image in-core. Probably the reason why you're running into issues is because of the fixup step of the dynamic linker. If you expect to use FIPS, you should link it as a hard dependency (also known as 'strict binding', as opposed to 'lazy binding') so that it can be loaded as early as possible, to minimize the chances of the linker needing to run fixups after application-code memory allocation. As you've found, the image in-core *must* match the original image in-core when the signature was generated, and the linker changes the pointers of where things are located when it has to. -Kyle H On Mon, Jan 18, 2010 at 2:48 AM, Bancroft, Matthew matt.bancr...@siemens-enterprise.com wrote: Hello, I have generated the fipscanister.o and all associated files as described in the user guide. All the checks ran ok. I have created an application using the fipscanister.o which works fine. When I create the shared library the run time check called when FIPS_mode_set() is called fails. I have found that depending on where I am loading the library in my code the signature generated is different. Hence my question, Is it really possible to create a shared library, and not an application, using the FIPS module? The make file for the shared lib looks like this: CC = gcc LIBOBJS= $(BIN)/fipsShared.o libfipsShared.so: fipsShared.o FIPSLD_CC=$(CC) /openssl-fips-1.2/fips/fipsld -shared -o $@ $^ -DDEBUG_FINGERPRINT_PREMAIN /openssl-fips-1.2/libcrypto.a The build platform is a native MIPS, gcc-3.4.4, make 3.81, uclibc.0.9.28. Regards, Matt Bancroft matt.bancr...@siemens-enterprise.com __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: FIPS linked as a shared library
The way that the FIPS module verifies its signature is that it forces itself to load (via a pre-main() section) and then calculate the checksum of the image in-core. Probably the reason why you're running into issues is because of the fixup step of the dynamic linker. If you expect to use FIPS, you should link it as a hard dependency (also known as 'strict binding', as opposed to 'lazy binding') so that it can be loaded as early as possible, to minimize the chances of the linker needing to run fixups after application-code memory allocation. As you've found, the image in-core *must* match the original image in-core when the signature was generated, and the linker changes the pointers of where things are located when it has to. -Kyle H On Mon, Jan 18, 2010 at 2:48 AM, Bancroft, Matthew matt.bancr...@siemens-enterprise.com wrote: Hello, I have generated the fipscanister.o and all associated files as described in the user guide. All the checks ran ok. I have created an application using the fipscanister.o which works fine. When I create the shared library the run time check called when FIPS_mode_set() is called fails. I have found that depending on where I am loading the library in my code the signature generated is different. Hence my question, Is it really possible to create a shared library, and not an application, using the FIPS module? The make file for the shared lib looks like this: CC = gcc LIBOBJS= $(BIN)/fipsShared.o libfipsShared.so: fipsShared.o FIPSLD_CC=$(CC) /openssl-fips-1.2/fips/fipsld -shared -o $@ $^ -DDEBUG_FINGERPRINT_PREMAIN /openssl-fips-1.2/libcrypto.a The build platform is a native MIPS, gcc-3.4.4, make 3.81, uclibc.0.9.28. Regards, Matt Bancroft matt.bancr...@siemens-enterprise.com __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: FIPS linked as a shared library
On 1/18/2010 2:42 PM, Kyle Hamilton wrote: The way that the FIPS module verifies its signature is that it forces itself to load (via a pre-main() section) and then calculate the checksum of the image in-core. Probably the reason why you're running into issues is because of the fixup step of the dynamic linker. If you expect to use FIPS, you should link it as a hard dependency (also known as 'strict binding', as opposed to 'lazy binding') so that it can be loaded as early as possible, to minimize the chances of the linker needing to run fixups after application-code memory allocation. As you've found, the image in-core *must* match the original image in-core when the signature was generated, and the linker changes the pointers of where things are located when it has to. Wouldn't applying the PIC compiler flag across all .o's accomplish the same thing? __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
