On 01/18/2013 09:25 AM, Jakob Bohm wrote: > On 1/18/2013 1:25 AM, Jeffrey Walton wrote: >> ... >> That's actually covered in the FIPS User Guide. >> >> 3.2.3 Assembler Optimizations >> ... >> >> For the x86/x86-64 and ARM processors several levels of optimization >> are support by the code. >> Note that most such optimizations, if compiled into executable code, >> are selectively enabled at >> runtime depending on the capabilities of the target processor. If the >> Module is built and executed >> on the same platform (the build-time and run-time systems are the >> same) then the appropriate >> optimization will be utilized (assuming that the build+target system >> corresponds to a formally >> tested platform). >> >> For x86-64 there are three possible optimization levels: >> 1. No optimization (plain C) >> 2. SSE2 optimization >> 3. AES-NI+PCLMULQDQ+SSSE3 optimization >> >> Note that other theoretically possible combinations (e.g. AES-NI only, >> or SSE3 only) are not >> addressed individually, so that a processor which does not support all >> three of AES-NI, >> PCLMULQDQ, and SSSE3 will fall back to only SSE2 optimization. >> The runtime environment variable >> disables use of >> AES-NI, PCLMULQDQ, and SSSE3 optimizations for x86-64. >> >> For ARM there are two possible optimization levels: >> 1. Without NEON >> 2. With NEON (ARM7 only) >> >> The runtime variable OPENSSL_armcap=0 disables use of NEON >> optimizations for ARM. In the case where the build and runtime systems >> are different care must be taken to verify that the >> optimizations enabled at run-time on the target system correspond to a >> formally test platform. For >> instance, if "Windows on x86 32bit" was formally tested but "Windows >> on x86 with AES-NI 32 >> bit" was not >> >> then a Module built on an AES-NI capable built system would be >> validated when >> executed on a non-AES-NI capable target processor, but would notbe >> validated when executed on >> an AES-NI capable system (such as the build system itself). >> > > This sounds very wrong! > > For platforms with runtime capability detection (such as x86 and > x86_64), modules compiled for that target platform *on any computer > capable of compiling or cross compiling for that target* should > include all the run-time selectable variants.
That is the case, the FIPS module compiled on *any* x86 build system (whether AES-NI capable or not) will include runtime support for AES-NI. The caution here about the buildtime system is directed at an issue peculiar to the FIPS 140-2 validation. The FIPS module is capable of runtime selection of AES-NI optimization, but if both cases (with and without) have not been formally tested for a platform then the untested case isn't validated. In the case of non-AES-NI being formally tested then use of the module with OPENSSL_ia32cap=~0x200000200000000 specified on an AES-NI processor would be legitimate, but if only the AES-NI optimized case has been formally tested then the module could not be used at all on a non-AES-NI system (that is used in terms of FIPS 140-2 validation; it will of course run just fine). That's a confusing and tricky situation with no obvious clean resolution, other than to test both optimized and non-optimized cases (which has indeed been done for a number of platforms). I'll see if I can word that a little more clearly in the document. -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 marqu...@opensslfoundation.com marqu...@openssl.com ______________________________________________________________________ OpenSSL Project http://www.openssl.org User Support Mailing List openssl-users@openssl.org Automated List Manager majord...@openssl.org
