Accelerating OpenSSL with CAAM

It seems like OpenSSL ignores by default availability of any cryptography accelerators. Did anyone succeed integrating this in Toradex Linux:

Enhance cryptodev and its engine in OpenSSL by CAAM’s public key cryptography operations

  • git clone https://gitee.com/zxd2021-imx/meta-openssl-caam.git -b Linux-5.4.70-2.3.4 to layers
  • add dunfell to LAYERSERIES_COMPAT_openssl-caam in layer.conf
  • copy linux-imx_5%.bbappend to linux-toradex_5.4-2.3.x.bbappend
  • add ${TOPDIR}/…/layers/meta-openssl-caam \ to bblayers.conf

Kernel seems being patched well, it builds OK. Out of tree cryptodev.ko seems being build, modprobe works. But openssl engine switch doesn’t work, it complains about missing *.so file under /usr/lib/engines-1.1/. I’ve no idea how to build it.

Edward

It seems the problem was package config in openssl_1.1.1caam.bb, it defaulted at disable-devcryptoconfig instead of enable:

PACKAGECONFIG[cryptodev-linux] = "enable-devcryptoeng,disable-devcryptoeng,cryptodev-linux,,cryptodev-module"

These 4 benchmarks run kind of 50 times faster with cryptodev.ko loaded:
openssl speed dsa
openssl speed rsa
openssl speed ecdsa
openssl speed ecdh

These benchmarks with optional and unnecessary -engine devcrypto switch run slower on small size blocks and faster on large size block. 16k block is about 2x faster with cryptodev loaded.
openssl speed -evp sha256 -engine devcrypto -elapsed
openssl speed -evp aes-128-cbc -engine devcrypto -elapsed
openssl speed -evp aes-128-ecb -engine devcrypto -elapsed
openssl speed -evp aes-128-cfb -engine devcrypto -elapsed
openssl speed -evp aes-128-ofb -engine devcrypto -elapsed
openssl speed -evp des-ede3 -engine devcrypto -elapsed
openssl speed -evp des-cbc -engine devcrypto -elapsed
openssl speed -evp des-ede3-cfb -engine devcrypto -elapsed

And there’s something wrong with openssl genrsa. It produces much shorter keys than expected with cryptodev loaded, as well calculation takes much longer with driver loaded. Perhaps I’m still doing something wrong.

Hi @Edward ,

Thank you for your investigation.

We will try to reproduce it on our end and let you know any information we gather in the process.

Best Regards
Kevin

Hi @kevin.tx,

I didn’t know about cryptodev at all until that post on NXP forum. Actually toradex Yocto recipies include cryptodev! It is easy to make cryptodev populated on rootfs, it modprobes well, but openssl doesn’t see it, looks like openssl is build is config doesn’t enable cryptodev support.

I overlooked that PACKAGECONFIG[cryptodev-linux] actually is about cryptodev-linux, not about openssl. For some reason modifying it helped to make openssl-caam recognising cryptodev. But it doesn’t help to make toradex openssl recognising cryptodev.

I perhaps could stick with openssl-caam, but it has some issues. For example this command misbehaves with openssl-caam and cryptodev loaded.
openssl s_client -connect www.google.com:443

All enhancements aren’t actually required, but it would be nice to have at least something accelerated in openssl, of course without breaking plain openssl functionality.

Regards
Edward

@kevin.tx,

Yocto recipes already include cryptodev layers, they just need to be enabled in openssl recipe.
These build in recipes don’t include support for all ciphers listed in article mentioned in first message, but at least they don’t break support for openssl genrsa and s_client commands. As well something like openssl speed -evp sha256 seems being way faster than I got with -caam recipe.

To enable cryptodev I crerated openssl_%.bbappend file with this line inside
PACKAGECONFIG += " cryptodev-linux"

It works well not only with imx7 and VF, which both have CAAM, yocto provided cryptodev works as well with imx6ull, which has DCP module instead of CAAM. Perhaps you could enable cryptodev for openssl by default. Anyway without cryptodev loaded openssl behaves the same like compiled with cryptodev disabled.

Edward

Hi @Edward ,

Thanks for your investigation and the update.

I will let the team know about this. They will then decide on how to go forward with this.

Best Regards
Kevin