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?
> >>> 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
>
