Bug 1025717

Summary:	missing AES-NI in "engine" Fedora compared to RHEL/CentOS?
Product:	[Fedora] Fedora	Reporter:	Harald Reindl <h.reindl>
Component:	openssl	Assignee:	Tomas Mraz <tmraz>
Status:	CLOSED NOTABUG	QA Contact:	Fedora Extras Quality Assurance <extras-qa>
Severity:	unspecified	Docs Contact:
Priority:	unspecified
Version:	18	CC:	tmraz
Target Milestone:	---
Target Release:	---
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2013-11-01 12:14:23 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description Harald Reindl 2013-11-01 11:20:43 UTC

affects F18/F19

why does Fedora's openssl not list "aesni" compared to RHEL?

the values below are showing it is in fact supported by both, on the
other hand "SSLCryptoDevice aesni" for Apache does not work on Fedora
and i am unsure if it is used automatically by default in that case

in doubt this may waste factor 8 in performance on modern hardware
http://httpd.apache.org/docs/2.4/mod/mod_ssl.html#sslcryptodevice
____________________________________________

cat /etc/redhat-release; openssl engine; cat /proc/cpuinfo | grep "model name"
CentOS release 6.4 (Final)
(aesni) Intel AES-NI engine
(dynamic) Dynamic engine loading support
model name      : Intel(R) Xeon(R) CPU           E5640  @ 2.67GHz

openssl speed aes-256-cbc
type             16 bytes     64 bytes    256 bytes   1024 bytes   8192 bytes
aes-256 cbc      58003.13k    62866.47k    63308.37k   135122.94k   135858.86k

openssl speed -evp aes-256-cbc
type             16 bytes     64 bytes    256 bytes   1024 bytes   8192 bytes
aes-256-cbc     460493.45k   508006.53k   517264.90k   519457.45k   520594.75k
____________________________________________

cat /etc/redhat-release; openssl engine; cat /proc/cpuinfo | grep "model name"
Fedora release 18 (Spherical Cow)
(dynamic) Dynamic engine loading support
model name      : Intel(R) Xeon(R) CPU           E5640  @ 2.67GHz

openssl speed aes-256-cbc
type             16 bytes     64 bytes    256 bytes   1024 bytes   8192 bytes
aes-256 cbc      58347.04k    63168.39k    64110.99k   135981.36k   137257.23k

openssl speed -evp aes-256-cbc
type             16 bytes     64 bytes    256 bytes   1024 bytes   8192 bytes
aes-256-cbc     462203.14k   512258.69k   519790.56k   522836.19k   523612.23k

Comment 1 Harald Reindl 2013-11-01 11:52:29 UTC

i found this changelog entry, but look below!

* Wed Aug 24 2011 Tomas Mraz <tmraz at redhat.com> 1.0.0d-8
- drop the separate engine for Intel acceleration improvements
  and merge in the AES-NI, SHA1, and RC4 optimizations
- add support for OPENSSL_DISABLE_AES_NI environment variable
  that disables the AES-NI support
_______________________________________________

two Apache benchmarks "ab -c 50 -n 20000" let me fear AES-NI is 
not used by httpd/openssl as default because without SSL the 
same call are 750 requests/second which means with encryption in 
both cases the same 475 less while AES-NI should boost by factor 5-8

/etc/sysconfig/httpd untouched:
Requests per second:    274.38 [#/sec] (mean)
Requests per second:    271.71 [#/sec] (mean)

OPENSSL_DISABLE_AES_NI=1:
Requests per second:    273.01 [#/sec] (mean)
Requests per second:    273.90 [#/sec] (mean)
_______________________________________________

http://httpd.apache.org/docs/2.4/mod/mod_ssl.html#sslcryptodevice
Default: SSLCryptoDevice builtin

the same values as above with
SSLCryptoDevice dynamic

Comment 2 Tomas Mraz 2013-11-01 12:14:23 UTC

There is no OPENSSL_DISABLE_AES_NI support in Fedora packages anymore. The AES-NI support is from upstream.

Comment 3 Harald Reindl 2013-11-01 12:24:47 UTC

thanks for feedback, that explains why i can't verify anything :-)

but this still smells like it is not used automatically compared "openssl speed aes-256-cbc" and "openssl speed -evp aes-256-cbc" or does this really only affect the becnhmark and in normal operations it's used?

Available options:
-engine e       use engine e, possibly a hardware device.
-evp e          use EVP e

Comment 4 Tomas Mraz 2013-11-01 12:36:15 UTC

No, the openssl call without the -evp calls directly the software implementation (no AES-NI). On the other hand all higher level applications including the TLS implementation call the EVP functions which automatically call the AES-NI accelerated implementation if available.

Of course if 3rd party program uses the low level interface directly calling the AES software implementation, it will not be accelerated, but that did not change from the situation in RHEL-6. Basically the low level interfaces should not be used by 3rd party programs ever but unfortunately these were part of the OpenSSL API and ABI for a long time so we cannot make them hidden.

Comment 5 Harald Reindl 2013-11-01 12:42:23 UTC

thank you so much helping understand how it works in details!

my intention by bringing up such things is to make best use of the own hardware in production while at the same time if things could be optimized all other users and maybe future development may benefit