Thanks Harvey,
This seems to have worked as far as getting the .rodata section used. This
is what I see now:
001b5740 g O .rodata 00000010 FIPS_rodata_start
001b5750 l O .rodata 00000011 FIPS_hmac_key
001b57bc g O .rodata 00000036 FIPS_bn_version
001c1e08 g O .rodata 00000010 FIPS_rodata_end
001fb1cc g O .data 00000014 FIPS_signature
My problem now is that when I build an executable (I'm using the simple
hmac.c example in the user guide, with the Makefile modified to use a
shared library) that uses the shared libcrypto.so, and run it on my target,
it just spits out a hash value, no matter what options I give it. For
example:
# ./hmac
334286d0c4ca79f97921fa782c7269e972e0a420
Before I used the suggested "-f" options, this app at least worked for
non-fips and gave me an error when enabling fips mode. Now I don't
understand what it is doing, but I think it is trying to tell me something!!
I've tried messing around with different INCORE_ADJUST values, but that
does not seem to make any difference. I don't really understand how incore2
is supposed to work: it calculates a lot of stuff and dumps out values but
never appears to modify the executable or library.
I've also tried static linking of libcrypto.a into the executable - same
result.
Help appreciated!
Kevin
On Thu, Feb 16, 2012 at 4:47 PM, Harvey Shepherd <
harvey.sheph...@aviatnet.com> wrote:
> Hi Kevin,
>
> I encountered this problem when compiling the 1.2.3 FIPS object module
> some time ago, with exactly the same compiler. After some experimentation I
> managed to get it to embed the fingerprint correctly using the following
> compiler options:
>
> -fno-common -fdata-sections -ffunction-sections
>
> I also needed to change the INCORE_ADJUST setting to an 8 byte offset for
> my processor as follows:
>
> diff --git a/current/appfs/openssl-fips/incore
> b/current/appfs/openssl-fips/incore
> index 07df989..61f68b9
> 100755 (executable)
> --- a/current/appfs/openssl-fips/incore
> +++ b/current/appfs/openssl-fips/incore
> @@ -6,6 +6,7 @@
>
> DEBUG=
>
> +CROSS_COMPILE=ppc_8xx-
> OBJCOPY=${CROSS_COMPILE}objcopy
> OBJDUMP=${CROSS_COMPILE}objdump
>
> @@ -58,6 +59,7 @@ if [ -z "$INCORE_ADJUST" ]; then
> elf64-x86-64) INCORE_ADJUST=4;;
> #elf32-littlearm|elf32-little|elf32-bigarm) INCORE_ADJUST="-36";;
> elf32-littlearm|elf32-little|elf32-bigarm) INCORE_ADJUST="-8";;
> + elf32-powerpc) INCORE_ADJUST=8;;
> esac
>
> fi
>
> I'm not really an expert in this area, but it worked for me, so give it a
> try.
>
> Regards,
> Harvey
>
>
>
> I am building a cross-compiled FIPS-capable libcrypto.so with the 1.0.1beta
> OpenSSL and 2.0 FIPS Object Module.
>
> The build is being done on a linux (CentOS) host for a PowerPC target
> running
> netbsd 1.6.2 (yes, I know, its old).
>
> gcc being used:
> $ ${CROSS_COMPILE}gcc -v
> gcc version 2.95.3 20010315 (release) (NetBSD nb3)
> (yes, I know, also old)
>
> I can successfully build fipscontainer.o, and then build fips_algvs, which
> runs successfuly on the target system. This made me think that the
> fingerprint was working correctly...
>
> Later (when building libcrypto.so) I realized I was using the native
> incore
> script instead of the cross-compile incore script. I switched to the
> cross-compile incore script, but that failed to embed a fingerprint in
> the (FIPS-capable) libcrypto.so.
>
>
> ______________________________________________________________________
> OpenSSL Project http://www.openssl.org
> User Support Mailing List openssl-users@openssl.org
> Automated List Manager majord...@openssl.org
>
