> 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.
Even though FIPS 2.0 util/incore is capable of handling arbitrary ELF binary (native or not), it's not used in non-cross-compile/native cases, as there *are* configurations when it won't work. In other words above statement does no hold universally true and FIPS 2.0 util/incore script is supported and should be used only in cross-compile environments targeting ELF, moreover, not *any* environment, but in explicitly verified (see below). > After I had gotten the extra "-f" options from Harvey for this platform > (BSD-powerpc), Using -f[data|function]-sections options is inappropriate as they undermine the idea of "capturing" fipscanister code and rodata between start/end symbols. It was bad advice/idea, do *not* use those options. > I learned a lot of interesting things along the way, so aside from time > spent and the bruised forehead, > everything is good. I'm not convinced that it is:-) Just because it appears working it doesn't necessarily mean it's doing the right thing. Every cross-compiler has to be explicitly verified, which is why there is no generic "one-size-fits-all" support for cross-compiling. > 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. Keep in mind that it will be counted as validated only as long as you don't change it. ______________________________________________________________________ OpenSSL Project http://www.openssl.org User Support Mailing List openssl-users@openssl.org Automated List Manager majord...@openssl.org
