On Sun, Feb 19, 2012 at 3:50 PM, Kevin Fowler <kevpfow...@gmail.com> wrote:
>
>
> On Sun, Feb 19, 2012 at 11:52 AM, Andy Polyakov <ap...@openssl.org> wrote:
>
>> >>> 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.
>>
>
> Ok, so I did this and added it to appropriate locations in fips_canister.c
> 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.
>
> How would you go about verifying this?
>
So I did what I mentioned above, more or less following the idea in
IncoreTutorial document,
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.
Thanks again for your guidance.
Kevin
>
>> >>> 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-...@openssl.org
>> Automated List Manager majord...@openssl.org
>>
>
>
