OpenSSL supports accelerating certain operations like SHA and AES using processor architecture specific mechanisms. This can be selected in the OpenSSL configuration process with configurations that inherit from architecture specific configs like asm("aarch64_asm") or asm("x86_64_asm"). We will likely need to update the UEFI config to add these configs like: inherit_from => [ "BASE_unix", asm("x86_64_asm"), , asm("aarch64_asm") ], To further complicate things the assembly language implementation in openssl requires a perl script to generate the appropriate assembly syntax for the requested toolchain, e.g.: perl crypto/aes/asm/aesv8-armx.pl linux64 crypto/aes/aesv8-armx.S The perl assembly generation will need to occur before the build - perhaps from the process_files.pl which resides in the OpensslLib directory. Lastly some changes will likely be required to get the build working for UEFI - hopefully these can be upstreamed to openssl.
I have already implemented the necessary changes, and will be sending a review soon. The current plan is to check in the generated assembly files just as we check in the generated header files. The initial OpenSSL changes are committed here but do not include aarch64: https://github.com/openssl/openssl/commit/1b72105076bb2e73f3c8461f9c0ca5ecefe007c8
Thanks Chris, I added Ard in hopes of getting AArch64 support.
There is another problem to use HW acceleration. CryptLib is not using EVP and it should be changed to use EVP.
Eugene Cohen: can you work on it?
Sung takes it.
this is a new feature.
This has been partially resolved with these commits: 878a92a887ef4ca879d336f323e91b13cc767a59 147f34b56ce0e2e18285ef7d0695753ac0aa5085 Acceleration of SHA variants is now possible. The current AES implementation in OpensslLib does not use the correct API to access the accelerated code in OpenSSL.
I was able to use ARM crypto extension for openssl with some patches that Chris provided. https://edk2.groups.io/g/devel/message/66701 https://edk2.groups.io/g/devel/message/66704?p=,,,20,0,0,0::recentpostdate%252Fsticky,,Add+EVP+implementation,20,2,0,77870226 There was a problem building openssl/crypto/armcap.c. This is because armcap.c is using some signal related functions like sigsetjmp, siglongjmp, etc. These functions are used to check if crypto instructions are supported. Since I already knew the capabilities of our system, I changed armcap.c and forced OPENSSL_armcap_P to a specific value. To support arm crypto extension fully in UEFI, I think that openssl code(armcap.c) should be updated.
From the EDK2 side, we cannot change the OpenSSL code, since it's pulled in as a submodule directly from OpenSSL. You might be able to add functionality to the getenv() function in CrtWrapper.c, and pre-populate the "OPENSSL_armcap" value somehow.
The following commits add IA32/X64 optimized versions https://github.com/tianocore/edk2/commit/a8e8c43a0ef25af133dc5ef1021befd897f71b12 https://github.com/tianocore/edk2/commit/4102950a21dc726239505b8f7b8e017b6e9175ec https://github.com/tianocore/edk2/commit/03f708090b9da25909935e556c351a4d9445fd3f And the following commit combines the optimized INFs https://github.com/tianocore/edk2/commit/ea6d859b50b692577c4ccbeac0fb8686fad83a6e With these changes, this feature can be closed as Resolved/Fixed. If optimization work is required for more openssl APIs or for other CPU atchs, then those can be entered as new feature requests.
