> Another option (but shoot it down if its bogus :-): I noticed that if I > compile > fipscanister.o without "-fPIC", then the const variables do get placed in > the (really readonly) .rodata section as desired. I thought maybe if I did > that and went the static route - build libcrypto with no-shared and link > libcrypto.a statically into my app - then maybe I would have a validate-able > solution.
The prime reason for why FIPS 2.0 module is compiled with -fPIC is to make it versatile. Idea is to validate *single* fipscanister.o usable in either context, statically-linked application or dynamic library. Reasoning is that while it's plain inappropriate to use non-PIC code in dynamic library, linking PIC statically was proven to work on all tested platforms, therefore -fPIC. This naturally means that if you are positively not interested in unified/versatile fipscanister.o nothing prevents you from giving up on -fPIC and targeting statically-linked application only. I.e. introducing config-line without -fPIC through change letter is as validate-able as anything else. > Per your comment below, FIPS_text_start (and end) also looks > correct in the disassembled code: > > 0181ae34 <FIPS_text_start>: > ... Yes, it looks proper. ______________________________________________________________________ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
