On Mon, Feb 20, 2012 at 5:18 AM, 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, e.g.,
.file "fips_aes_selftest.c"
gcc2_compiled.:
.section ".rodata","aw"
.type tests,@object
tests:
.byte 0
...
The objdump -h also shows for this section:
11 .rodata 0000c724 018725d0 018725d0 000725d0 2**3
CONTENTS, ALLOC, LOAD, DATA
so not READONLY.
The assembler, which apparently recognizes .rodata for what it is,
generates a warning about setting incorrect attributes for .rodata
section.
>
> >> 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?
This is in the docs section for the previous validation.
http://opensslfoundation.com/testing/validation-1.2/docs/
>
> > 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).
The assembler code looks correct for FIPS_text_startX returning its
memory location.
> ______________________________________________________________________
> 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
