AES hardware acceleration using AES-NI and ARMv8 CE #803
Conversation
Introduce aes128 library code that uses hardware accelerated AES on architectures where it's supported, and will fall back to the existing software AES (Rijndael) if built without hardware acceleration, or if hardware acceleration is not supported by the CPU at run-time. For now it's opt-in and requires -DWITH_AES_HW cmake argument to build. Acceleration implemented for x86_64 (AES-NI) and arm64 (ARMv8 CE). Adopt new aes128 abstraction in validate and aesrand. On hardware configurations where scan rate is limited by CPU, hardware-accelerating AES can substantially improve scan rate, because packet validation as currently implemented requires an AES block encryption for every packet sent and received.
There was a problem hiding this comment.
I still need to go through this more thoroughly but overall this looks great and a much needed/appreciated improvement. Especially with your other improvements on increasing send rate, CPU bottlenecking becomes more possible.
Do need to request changes to the copyright, more details in my comment, but thank you overall!
|
To be fair, while this was fun and turned out more presentable than I initially feared, it would probably be better to replace the hw acceleration bits (as well as the software Rijndael routines) with OpenSSL at some point, for an always-on solution. I just could not bring myself to deal with the plethora of portability challenges that come with using the various flavours of OpenSSL. |
|
Yeah, I don't really want to have to deal with OpenSSL in all honesty. I think given that this is a performance optimization that you'd probably only really care about for super high send rates, it's fine to have it only work on x86_64 and arm64 is pretty reasonable. |
Introduce aes128 library code that uses hardware accelerated AES on architectures where it's supported, and will fall back to the existing software AES (Rijndael) if built without hardware acceleration, or if hardware acceleration is not supported by the CPU at run-time.
For now hardware acceleration is opt-in and requires
-DWITH_AES_HWcmake argument to build. Acceleration implemented for x86_64 (AES-NI) and arm64 (ARMv8 CE) using compiler intrinsics, no assembly.Adopt new aes128 abstraction in validate and aesrand. Invoke quick selftest at ZMap start, to ensure correct operation regardless of which AES implementation is being used.
On hardware configurations where scan rate is limited by CPU, hardware-accelerating AES can substantially improve scan rate, because packet validation as currently implemented requires an AES block encryption for every packet sent and received. I'm seeing a scan rate improvement from 10.28 Mp/s to 12.13 Mp/s with netmap on 10 GbE when using AES-NI instead of software AES.
Tested on macOS Sonoma (ARMv8 CE, clang), FreeBSD 14.0 (both AES-NI and ARMv8 CE, clang), and Ubuntu 23.10 (ARMv8 CE, GCC).