Cryptodev/af_alg engines in OpenSSL on STM32MP157C-DK2 do not provide hash algorithms for hardware acceleration

[Paradox]

Hello,

I have successfully compiled and deployed the distribution package (trusted) onto the STM32MP1. I am using OpenSSL in a program for signing data, where SHA256 is used as a hash. I would like to take advantage of hardware acceleration by using either the cryptodev or af_alg engines. The distribution provides Yocto recipes for cryptodev-linux (header), cryptodev-module (kernel module) of version 1.9 and for OpenSSL version 1.1.1b, in which I modified the PACKAGECONFIG line by adding cryptodev-linux option in it, so OpenSSL compiles with the cryptodev support. The 3 aforementioned recipes were built and deployed using devtool. OpenSSL also provides a built-in AF_ALG engine by default. However, the supported algorithms of both engines are only ciphers, there are no hash algorithms whatsoever. I also tried to build OpenSSL with the -DUSE_CRYPTODEV_DIGESTS, but that didnt change anything. Version 1.0.2 of OpenSSL however, provides some hashing algorithms like MD5 and SHA1, but not SHA256. I have also posted an issue on OpenSSL github, but maybe there is a problem on STM side. The output of cat /proc/crypto lists

SHA256 among many other hashes, which means it should be supported.

I would appreciate any help regarding this issue.

[Bernard PUEL]

I have tried same as you did but never got the cryptodev engine appeared in openssl. Very frustrating indeed ...

I will enter an internal ticket for integration team and let you know. If you get some updates on your side please let me know.

[Paradox]

Now thats interesting. It should not differ from my case, since it is the same board. Are you sure you are running the newest version of st-image-weston image? I have literally just built that image and flashed the FlashLayout_sdcard_stm32mp157c-dk2-trusted version using STM32CubeProgrammer. Afterwards I used devtool to build the 3 recipes that I mentioned in my first post and deployed them onto the board. If that does not work, I don't know what would. I think I will not waste any more time finding out why it does not show any hashes, I will proceed with what I have gotten, but I am curious about how this works out. Thank you for your time and support though, I very much appreciate it.

[Bernard PUEL]

Hello,

investigation of this issue continued on our integration team. Here is the outcome:

for Dunfell, if openssl is compiled with 'cryptodev-linux' (PACKAGECONFIG_append_pn-openssl = " cryptodev-linux") then only need to 'modprobe cryptodev' and HW acceleration is working.

root@stm32mp1:~# time openssl speed -evp sha256 -engine devcrypto

engine "devcrypto" set.

Doing sha256 for 3s on 16 size blocks: 27948 sha256's in 0.27s

Doing sha256 for 3s on 64 size blocks: 26880 sha256's in 0.24s

Doing sha256 for 3s on 256 size blocks: 21500 sha256's in 0.14s

Doing sha256 for 3s on 1024 size blocks: 20334 sha256's in 0.19s

Doing sha256 for 3s on 8192 size blocks: 12768 sha256's in 0.14s

Doing sha256 for 3s on 16384 size blocks: 8919 sha256's in 0.10s

OpenSSL 1.1.1f 31 Mar 2020

built on: Tue Mar 31 12:17:45 2020 UTC

options:bn(64,32) rc4(char) des(long) aes(partial) idea(int) blowfish(ptr)

compiler: arm-ostl-linux-gnueabi-gcc -mthumb -mfpu=neon-vfpv4 -mfloat-abi=hard -mcpu=cortex-a7 --sysroot=recipe-sysroot -O2 -pipe -g -feli

minate-unused-debug-types -fmacro-prefix-map= -fdebug-prefix-map= -fdebug-prefix-map=

-fdebug-prefix-map= -DOPENSSL_USE_NODELETE -DOPENSSL_PIC -DOPENSSL_CPUID_OBJ -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_GF2m -DSHA1_

ASM -DSHA256_ASM -DSHA512_ASM -DKECCAK1600_ASM -DAES_ASM -DBSAES_ASM -DGHASH_ASM -DECP_NISTZ256_ASM -DPOLY1305_ASM -DNDEBUG

The 'numbers' are in 1000s of bytes per second processed.

type 16 bytes 64 bytes 256 bytes 1024 bytes 8192 bytes 16384 bytes

sha256 1656.18k 7168.00k 39314.29k 109589.56k 747110.40k 1461288.96k

real 0m 18.23s

user 0m 1.08s

sys 0m 7.36s

[Bernard PUEL]

You can see the results are really good. Then Dunfell is for the next delivery planned end of June (V2.0.0).

My feeling is that the pb is pure openssl recipe in Thud but backporting openssl from Dunfell to thud is probably difficult (many dependencies).

How do you see that ?

[Paradox]

Hello,

thanks a lot for all of the effort to everyone involved. If the results are correct, then this is a great performance improvement. If I understood correctly, this will be supported in the next software release sometime in June? If so, I will implement it as soon as it releases.

[Bernard PUEL]

Yes STM32MP15 ecosystem release V2.0.0 is planned for end of June. It will be based on first Yocto LTS (Long term support) named Dunfell and kernel 5.4.

[Paradox]

Thanks very much again to you and everyone on the integration team. I will update this thread once I successfully implement this and then close it.