Speed up AES-256-GCM on aarch64 to (at least) armv4 level

[rfjakob]

I have a Raspberry Pi 4, and I am benchmarking AES-256-GCM on 32 vs 64-bit-arm Debian Bullseye.

OpenSSL 3.0.0 was compiled from source, config dumps:

• arm 64 bit (asm_arch => "aarch64"): https://gist.github.com/rfjakob/82fb1ca5e1f6f7756b7a4b9dc2ca4783
• arm 32 bit (asm_arch => "armv4"): https://gist.github.com/rfjakob/bb999b293201ff257349672e5aa9aeba

Interestingly, the armv4 version is 2.3 times faster than the aarch64 version.

arm 32 bit:

root@f13b37d6334c:~/openssl-3.0.0# LD_LIBRARY_PATH=$PWD ./apps/openssl speed -evp aes-256-gcm
[...]
version: 3.0.0
built on: built on: Thu Sep  9 14:48:50 2021 UTC
options:bn(64,32) 
compiler: gcc -fPIC -pthread -Wa,--noexecstack -Wall -O3 -DOPENSSL_USE_NODELETE -DOPENSSL_PIC -DOPENSSL_BUILDING_OPENSSL -DNDEBUG
CPUINFO: OPENSSL_armcap=0x3
The 'numbers' are in 1000s of bytes per second processed.
type             16 bytes     64 bytes    256 bytes   1024 bytes   8192 bytes  16384 bytes
AES-256-GCM      42906.57k    48964.74k    50933.59k    54975.15k    56318.63k    55885.82k

arm 64 bit:

root@b135577e8e14:~/openssl-3.0.0# LD_LIBRARY_PATH=$PWD ./apps/openssl speed -evp aes-256-gcm
[...]
version: 3.0.0
built on: built on: Thu Sep  9 15:45:52 2021 UTC
options:bn(64,64) 
compiler: gcc -fPIC -pthread -Wa,--noexecstack -Wall -O3 -DOPENSSL_USE_NODELETE -DOPENSSL_PIC -DOPENSSL_BUILDING_OPENSSL -DNDEBUG
CPUINFO: OPENSSL_armcap=0x83
The 'numbers' are in 1000s of bytes per second processed.
type             16 bytes     64 bytes    256 bytes   1024 bytes   8192 bytes  16384 bytes
AES-256-GCM      22017.32k    23275.02k    23746.56k    23875.93k    23953.41k    24033.52k

[xtkoba]

Interesting. 64-bit build is faster on my Android phone with Qualcomm SDM632:

~/64$ LD_LIBRARY_PATH=. ./openssl speed -evp aes-256-gcm
[...]
version: 3.0.0
built on: built on: Thu Sep  9 15:56:56 2021 UTC
options:bn(64,64)
compiler: aarch64-linux-android21-clang -fPIC -pthread -Wa,--noexecstack -Qunused-arguments -Wall -Oz -U__ANDROID_API__ -DOPENSSL_USE_NODELETE -DOPENSSL_PIC -DOPENSSL_BUILDING_OPENSSL -DNDEBUG -D__ANDROID_API__=21
CPUINFO: OPENSSL_armcap=0x3f
The 'numbers' are in 1000s of bytes per second processed.
type             16 bytes     64 bytes    256 bytes   1024 bytes   8192 bytes  16384 bytes
AES-256-GCM     138553.43k   379550.01k   659447.35k   936420.94k  1084508.47k  1096681.40k

~/32$ LD_LIBRARY_PATH=. ./openssl speed -evp aes-256-gcm
[...]
version: 3.0.0
built on: built on: Thu Sep  9 15:33:09 2021 UTC
options:bn(64,32)
compiler: armv7a-linux-androideabi19-clang -fPIC -pthread -Wa,--noexecstack -Qunused-arguments -Wall -Oz -U__ANDROID_API__ -DOPENSSL_USE_NODELETE -DOPENSSL_PIC -DOPENSSL_BUILDING_OPENSSL -DNDEBUG -D__ANDROID_API__=19
CPUINFO: OPENSSL_armcap=0x3d
The 'numbers' are in 1000s of bytes per second processed.
type             16 bytes     64 bytes    256 bytes   1024 bytes   8192 bytes  16384 bytes
AES-256-GCM     130857.46k   332904.90k   560354.46k   673983.44k   714008.14k   713310.21k

[rfjakob]

Wow, that CPU's a beast. If I read OPENSSL_armcap correctly, we have:

Android Phone / Qualcomm SDM632:

• 32 bit: OPENSSL_armcap=0x3d = ARMV7_NEON + ARMV8_AES + ARMV8_SHA1 + ARMV8_SHA256 + ARMV8_PMULL
• 64 bit: OPENSSL_armcap=0x3f = all of the above + ARMV7_TICK (curious!)

Raspberry 4 / Broadcom BCM2711:

• 32 bit: OPENSSL_armcap=0x3 = ARMV7_NEON + ARMV7_TICK
• 64 bit: OPENSSL_armcap=0x83 = ARMV7_NEON + ARMV7_TICK + ARMV8_CPUID

So I guess only the software implementation on aarch64 is slow, if you have hardware AES, it's fast.

[bernd-edlinger]

Interestingly, the armv4 version is 2.3 times faster than the aarch64 version.

This should not make you feel safe, most likely the armv4 uses the non-constant time assembler
module while the aarch64 uses the constant time software implementation,
However you can opt in the old non-constant time software fallback when you configure with
-DOPENSSL_NO_AES_CONST_TIME to get comparable numbers.

[davidben]

Given these chips all have NEON, I suspect that's not all of it. For ARMv8 chips without crypto extensions (sigh), the 32-bit code still has some NEON paths, while the 64-bit code does not. Specifically:

• 32-bit ARM has a NEON GHASH implementation, using this technique. We have a translation of it to aarch64. Though our motivation was constant-time, not performance. (At the time, our GHASH fallback was not constant-time. Now it is, using BearSSL's technique.)
• 32-bit ARM has a bitsliced AES implementation (bsaes), that probably outperforms the permutation one (vpaes). IIRC, permutation instructions in NEON don't perform great. Though there's some low-hanging fruit available in actually using the _vpaes_encrypt_2x function that's lying around. Note bsaes has some tricky tradeoffs because it needs help from another implementation that historically was not constant-time. Not sure what the state of that is in OpenSSL. We had to do some work to resolve that.

But platforms really ought to be including crypto extensions at this point. It's unfortunate we standardized on something so software-unfriendly, but AES-GCM really wants hardware support.

[bernd-edlinger]

#15916 and #14592 might be of interest?

[nhorman]

I'm having a hard time seeing the outcome of this issue. From reading it it sounds like the resolution was the observation that the aarch64 target has no hardware offload support for AES-GCM, and so the software only solution it has to use is signficantly slower. Is there additional work to be done here?

[nhorman]

no response
marking as inactive, to be closed at the end of 3.4 dev, barring further input

[rfjakob]

64-bit ARM is missing some NEON-optimized code paths that 32-bit ARM has acc. to #16573 (comment) .

But this only matters for CPUs without ARMV8_AES/ARMV8_PMULL, and they are a dying breed.