On Tue, Feb 21, 2012 at 1:11 PM, Andy Polyakov <ap...@openssl.org> wrote:
>>>>>> 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.
>>>>>>
>>>>> Ok, so I did this and added it to appropriate locations in
>>>>> fips_canister.c
>>> Right, you need the __attribute__ in question even for
>>> FIPS_rodata_[start|end]. I failed to mention this. Good catch.
>>>
>>
>> Well, this idea at first looked like it would do the trick, however,
>> when the __attribute__((section(".rodata"))) call makes a ".rodata"
>> section, it isn't *the* .rodata section, it is just *a* .rodata
>> section and in fact is made writeable,
>
> Well, then it's tough break, switch to another compiler.
>
> Of course one can name section something else, e.g. ".rofips", and write
> a script that would set the read-only flag in fipscanister.o after it's
> linked. Or! It would be possible to modify incore to set the flag. I
> mean fipscanister.o can have .rofips that is not read-only, but it can
> become read-only in applications and shared lib in the process of
> embedding the signature. Well, whatever you do requires code change, so
> you have to validate it separately (change letter through
> opensslfoundation.com might be alternative)...
>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. I checked that the FIPS-bounded .text and .rodata regions are the same for the app and the fipscanister.o, and the app integrity test passes and fips mode gets enabled on the target. Per your comment below, FIPS_text_start (and end) also looks correct in the disassembled code: 0181ae34 <FIPS_text_start>: 181ae34: 3c 60 01 82 lis r3,386 (0x1820000) 181ae38: 38 63 ae 40 addi r3,r3,-20928 ( - 0x51c0) 181ae3c: 4e 80 00 20 blr ( = 0x181ae40) 0181ae40 <FIPS_text_startX>: 181ae40: 7c 08 02 a6 mflr r0 181ae44: 48 00 00 05 bl 181ae48 <FIPS_text_startX+0x8> 181ae48: 7c 68 02 a6 mflr r3 181ae4c: 7c 08 03 a6 mtlr r0 181ae50: 4e 80 00 20 blr I am expecting to have to do a change letter validation - just trying to minimize the necessary changes so that it will qualify for that option rather than a full-blown validation - which probably would not be viable for us. I assume that if a target can't support shared libraries properly then it is still ok to have the static alternative validated..? >> The assembler code looks correct for FIPS_text_startX returning its >> memory location. > > The question was if FIPS_text_start returns FIPS_text_startX's address > [of its first instruction], *not* what does FIPS_text_startX return! > ______________________________________________________________________ > OpenSSL Project http://www.openssl.org > Development Mailing List openssl-dev@openssl.org > Automated List Manager majord...@openssl.org ______________________________________________________________________ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
