BeauSlim

OpenSSL is user-space, so you need to use AF_ALG (or Cryptodev but that's kind of old-school) to bridge to kernel-space and access the rk_crypto driver. I looked at this (referring to some Marvell pogo-plug era documentation) but never bothered to sort out all the pieces needed. My application was a VPN, and I went the easy way and used IPSec, which lives in kernel-space. A good kernel module, StrongSwan, and the related NetworkManager plugin and you *should* be good to go. But, like I mentioned in my post above: with no module loaded, traffic flows fine. With the module loaded, I got no traffic and usually had a whole-board lockup. AFAIK, many of the v8 chips out now support ARM crypto acceleration so there's little point in mucking with something proprietary except out of curiosity.

It would be nice to be able to use hardware crypto for VPNs. The rockchip's hardware crypto acceleration has apparently been supported since Kernel 4.5. I noticed that the CONFIG_CRYPTO_DEV_ROCKCHIP option hadn't been compiled into the standard Armbian builds, so I built a custom kernel. Having the rk_crypto module loaded gives me additional ciphers in /proc/crypto as expected. Without the module loaded (either blacklisted with my build, or with the normal Armbian kernel), my tunnel (IKEv2/IPSEC w Strongswan) works fine. But with the module installed, no traffic passes. Sometimes I see kernel errors in syslog. A couple of times the box has locked up. I tried a -next build and a -dev build. I tried applying the 2 patches (https://patchwork.kernel.org/patch/9858691/ etc) from July onto the -dev build. No joy. Unfortunately, I'm used to working on PC hardware where AES-NI pretty much "just works," so I'm not really sure where to go from here. Am I missing something? Was the kernel module excluded due to a known issue? As a total aside, when I did the -next build, I enabled XZ for squashfs. This allows Ubuntu's snapd stuff to run. Works really very well on Armbian/Tinker. Worth including in the standard Armbian builds?