On Thu, Jan 17, 2013 at 4:21 PM, MauMau <maumau...@gmail.com> wrote:
> Hello,
>
> I'm using OpenSSL 1.0.1c on Linux and Windows to implement encryption
> feature of my software. I need to compare performance of cases where AES-NI
> is enabled and where it is disabled on the same computer. If possible, I
> want to avoid rebooting the computer for some reasons.
>
> Is it possible to turn on and off AES-NI of OpenSSL with any configuration?
> I appreciate it if it is possible to switch AES-NI without re-building
> OpenSSL.
That's actually covered in the FIPS User Guide.
3.2.3 Assembler Optimizations
The only option for processor architectures other than x86/x86-64 and
ARM is to use the pure C
language implementation and not any of the hand-coded performance
optimized assembler as each
assembler implementation requires separate FIPS testing. For example,
an Itanium or PowerPC
system can only build and use the pure C language module.
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 OPENSSL_ia32cap=~0x200000200000000
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).
When the target platforms are not known to have capabilities
corresponding to tested platforms
then the risk of inadvertently utilizing the unvalidated optimizations
at run-time can can be avoided
by setting the appropriate environment variables at run-time
Disabling run-time selectable optimizations
Platform Environment Variable Value
x86/x86-64 OPENSSL_ia32cap ~0x200000200000000
ARM OPENSSL_armcap 0
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List openssl-users@openssl.org
Automated List Manager majord...@openssl.org
