On Fri, Feb 17, 2012 at 10:25 PM, Dr. Stephen Henson <st...@openssl.org>wrote:
> On Fri, Feb 17, 2012, Kevin Fowler wrote: > > > 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. > > > > You need to use the "fipsld" script to link the target. It obtains the > signature and embeds it. You need to set FIPS_SIG environment variable to > point to the incore script. > > Steve. > Yes, I was doing that, but I was getting the procedure for the older FIPS/OpenSSL version mixed up with the one for the new FIPS/OpenSSL version. The key thing I realized is that the incore script that comes with the FIPS Object Module v2.0 tarball handles both native AND cross-compile scenarios. I had thought for cross-compiling we needed to replace it with the incore2 script on the website (like I think incore.gz was needed with the previous FIPS release..?). After I had gotten the extra "-f" options from Harvey for this platform (BSD-powerpc), I kept trying to get it to work with the incore2 script, but didn't really know what to do with it. I ended up embedding the signature "by-hand" by running a test app on my target, getting the hash it spat out, and then rebuilding the libcrypto.so with -DHASH_SHA1_SIG set to that hash. Then, while solving the "what should INCODE_ADJUST be for my platform" issue, the answer I figured out helped me to see that the FIPS_text_startX/endX symbols used by the latest incore script for v2.0 solves the whole problem for cross-compiled binaries and embeds the correct signature in the correct location without all the "by-hand" stuff. I rebuilt the whole thing pointing FIPS_SIG to the correct incore script, with the necessary compiler options from Harvey for this platform/compiler, and then everything worked fine automatically. I learned a lot of interesting things along the way, so aside from time spent and the bruised forehead, everything is good. I have now had to add one line to config, Configure, and fips_canister.c in the FIPS module to get it to work on my target. Oh well. Kevin -- > Dr Stephen N. Henson. OpenSSL project core developer. > Commercial tech support now available see: http://www.openssl.org > ______________________________________________________________________ > OpenSSL Project http://www.openssl.org > Development Mailing List openssl-...@openssl.org > Automated List Manager majord...@openssl.org >
