Can AES-NI be disabled?

[MauMau]

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.


Regards
MauMau

______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List openss...@openssl.org
Automated List Manager majo...@openssl.org

[Jeffrey Walton]

On Thu, Jan 17, 2013 at 4:21 PM, MauMau <maum...@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

[MauMau]

From: "Jeffrey Walton" <nolo...@gmail.com>

> That's actually covered in the FIPS User Guide.

Oh, I didn't imagine that the way of disabling AES-NI was described in FIPS
document.

> The runtime environment variable OPENSSL_ia32cap=~0x200000200000000
> disables use of
> AES-NI, PCLMULQDQ, and SSSE3 optimizations for x86-64.

That's exactly what I wished for. I'll try it.

Regards
MauMau

[Jakob Bohm]

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 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).
>

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.

Otherwise users who use robotic autobuilders running on a farm of build
machines will be getting somewhat random results depending on which
machine picks up the build job on any given day.

This way, there is only one possible x86 compilation result, with
3 possible runtime hardware dependent behaviors, not a 3x3 matrix
of possible host/target capability combinations. Ditto for x86_64
(maybe 2 possibilities not 2x2) and arm (2 possibilities not 2x2).


Enjoy

Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S. http://www.wisemo.com
Transformervej 29, 2730 Herlev, Denmark. Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded

[Steve Marquess]

>> 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
marq...@opensslfoundation.com
marq...@openssl.com