>>> 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.
>>
> Ok...so the original issue was that no .rodata section was being created,
> so no incore script (of any kind) worked. I had the impression that there
> needed
> to be a read-only data section to protect certain data.
This is correct impression, but it doesn't make -fdata-sections appropriate.
> So what would you
> suggest I try - what has been done with other compilers that do this?
Well, it says what has been "done" [in the single case encountered by
then] in User Guide 1.2: users are advised to *use another compiler*, in
other words nothing.
> I can't (don't want to?) believe this just dead-ends with no solution.
But you can/do accept that compiler has to be ANSI C-compliant in order
to compile OpenSSL. Indeed, I don't hear you complaining about OpenSSL
being impossible to compile with K&R C. In other words it's perfectly
reasonable to impose some requirements on compiler, isn't it? And so
just like compiler is required to be ANSI C to compile OpenSSL at all,
it's required to discriminate read-only data (by placing it to dedicated
segment) to compile FIPS module in particular. If your compiler doesn't
meet the minimal requirement, tough break, but that's the way it is.
Though in FIPS 2.0 there is new option that might work in this case.
Besides switching to another compiler that is. Introduced to rectify
situation with rodata segments not being position-independent on Win64,
defining __fips_constseg might prove useful even in this situation. See
if defining it in fips/fipssyms.h to __attribute__((section(".rodata")))
makes it work. Keep in mind that me suggesting this doesn't make it
validated. If it works, it still has to be separately validated by
authorities.
>>> 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.
>>
>>
> Ok, I get that - but the criteria needed to achieve explicit verification
> for a given cross-compilation scenario is not clear to me.
Criteria is very simple (and is not specific to cross-compile case(*)):
machine instructions comprising FIPS module has to reside between
addresses returned by FIPS_text_start and FIPS_text_end. Similar applies
to constant data, but it's the code segment that can tricky. Question
here is how do you know that current implementation of
FIPS_text_[start|end] actually does that on arbitrary platform? And the
answer is you don't. You don't know if FIPS_text_start returns address
on a machine instruction to start with, nor that linker doesn't
rearrange code(**) in such manner that machine instructions end up
outside the addresses in question. It was fortunate that current
implementation worked on cross-compiler platforms we've looked at so
far(***), but we can/may *not* assume that it holds universally true and
provide "one-size-fits-all" support for cross-compiling. Admittedly it's
very likely that current implementation would work even on platform in
question, but it can't be established without verifying.
(*) What is specific to cross-compile case is that addresses returned by
FIPS_text_[start|end] has be those of instructions constituting
FIPS_text_[start|end]X.
(**) Which is the very reason why -f*-segments options are
inappropriate, they [are documented to] facilitate rearranging of
code/data at linker stage.
(***) It worked because ld -r merged .text segments without changing
their order and that FIPS_text_[start|end] did return addresses of
machine instructions.
______________________________________________________________________
OpenSSL Project http://www.openssl.org
Development Mailing List openssl-dev@openssl.org
Automated List Manager majord...@openssl.org
