On 03/28/2013 11:30 AM, Abhijit Ray Chaudhury wrote:
> Steve,
>
> Thanks a lot for your explanation. I am not clear on one crucial point.
>
> Below are the steps I used to build fipscanister.o:
>
> 1. export env variables. (note CROSS_COMPILE="/opt/fip-tools/"; and
> /opt/fip-tools/gcc is a shell script).
Same answer as before: "... IMHO passing arbitrary compiler options by
any means is a gray area. ... In similar situations I advise our clients
not to take such liberties. ... Absent clear guidance from the CMVP
you'll need to decide your comfort level with making that claim."
The Security Policy and CMVP scripture do not specifically forbid
"stealth" specification of arbitrary compiler options, but doing so is
arguably contrary to the spirit of the validation process. Note the CMVP
took pains to forbid the use of ./config or make command line arguments,
which are otherwise often used for the same effect.
In general I hate to quote scripture, because that just ducks the
question at issue, but in this case the relevant part of I.G. G.5 is
worth study:
"The CMVP allows user porting of a validated software, firmware or
hybrid cryptographic module to a operational environment which was not
included as part of the validation testing. The validation status is
maintained in the new operational environment without retesting in the
new operational environment as long as the porting rules are followed.
However, the CMVP makes no statement as to the correct operation of the
module or the security strengths of the generated keys when ported and
executed in an operational environment not listed on the validation
certificate. ...
Note: A user may post-validation recompile a module if the unmodified
source code is available and the module’s Security Policy provides
specific guidance on acceptable recompilation methods to be followed as
a specific exception to this guidance. The methods in the Security
Policy must be followed without modification to maintain validation
under this guidance."
Are you using unmodified source code? Presumably yes. Does the Security
Policy describe compilation? Yes ("./config; make", no ./config options
allowed). Does it provide "specific guidance on acceptable recompilation
methods"? Well, good question.
Tweaking of compiler options is commonly done for porting, and passing
them the way you did (by binding them to all compiler references) is a
common technique. So one *could* argue that G.5 user affirmation covers
typical porting techniques, as long as the source is not modified and
the canonical "./config; make" is used. We don't make that argument here
at OSF. If you ever get a clear and definitive answer to that (from the
CMVP) please share it.
-Steve M.
--
Steve Marquess
OpenSSL Software Foundation, Inc.
1829 Mount Ephraim Road
Adamstown, MD 21710
USA
+1 877 673 6775 s/b
+1 301 874 2571 direct
[email protected]
[email protected]
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List [email protected]
Automated List Manager [email protected]
