>>> 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.cRight, you need the __attribute__ in question even for FIPS_rodata_[start|end]. I failed to mention this. Good catch. >> all with some #if's to try to limit the changes to >> my platform, and it seems to work. I say "seems" because it looks - >> to me - pretty much like it did before when I thought it was >> working, except that the .o file doesn't have a symbol per >> function. etc. >> >> So I don't know how to check if the sequestered code is located >> between the FIPS_text endpoints. I guess I can dump the >> fipscontainer.o symbols, and then dump the symbols in an executable >> that statically links it, and check that there has been no >> rearranging. I'm not sure how to check an executable that >> dynamically links libcrypto.so, since I do not have e.g., objdump >> or the like on the embedded target. But there ought to be cross-compile objdump you can run on the system you're cross-compiling on. >> How would you go about verifying this? >> > > So I did what I mentioned above, more or less following the idea in > IncoreTutorial document, I don't know what "IncoreTutorial document" is. What is it? > and could show that the symbols between > FIPS_start/end are exactly the same in fipscontainer.o, libcrypto.so, > and an app that statically links libcrypto.a. Same for > FIPS_rodata_start/end. And it runs on the target. For the app the app > symbols (and non-fipscanister crypto) are outside the sequestered > area. > > I'm not sure what else to do to verify that it is correct now. Please > suggest any additional tests I can do. The ultimate test is to run it under debugger and verify that value returned by FIPS_text_start is indeed pointer to first instruction of FIPS_text_startX. Set break point to FIPS_text_start, single-step till it returns, note the value in r3 register, 'disassemble FIPS_text_startX' and compare addresses. It's also possible to verify by examining disassembled code (objdump -d) and if necessary relocation tables (more than likely necessary in shared library case), but it's more complicated (specially in shared library case). ______________________________________________________________________ OpenSSL Project http://www.openssl.org User Support Mailing List openssl-users@openssl.org Automated List Manager majord...@openssl.org
