lobster Posted January 26, 2021 Posted January 26, 2021 Hi All, I have a RockPi4B and am using Armbian buster 5.9.14 downloaded from the RockPi page. One of my main motivations for getting the RockPi4 was its hardware AES capabilities. I can confirm this via $ grep aes /proc/cpuinfo Features : fp asimd evtstrm aes pmull sha1 sha2 crc32 cpuid Features : fp asimd evtstrm aes pmull sha1 sha2 crc32 cpuid Features : fp asimd evtstrm aes pmull sha1 sha2 crc32 cpuid Features : fp asimd evtstrm aes pmull sha1 sha2 crc32 cpuid Features : fp asimd evtstrm aes pmull sha1 sha2 crc32 cpuid Features : fp asimd evtstrm aes pmull sha1 sha2 crc32 cpuid That said, I'm not entirely sure that the necessary module has been built into the kernel. I'm currently checking via: $ sort -u /proc/crypto | grep module module : kernel module : zstd and I expected to see something that looked like "aes" OpenSSL also doesn't seem to find anything: $ openssl engine (dynamic) Dynamic engine loading support In fact I see no crypto modules loaded at all: $ lsmod | grep aes $ lsmod | grep crypto $ I do see the "rk_crypto" module and can load it no problem, but it doesn't seem to do anything in the context of the above (apart from showing up under "lsmod"). So my question is whether I'm getting hardware AES acceleration on my RockPi4 with stock Armbian. From what I can see the answer is no, but I'm hoping I've missed something. Thanks!
Igor Posted January 26, 2021 Posted January 26, 2021 2 hours ago, lobster said: So my question is whether I'm getting hardware AES acceleration on my RockPi4 with stock Armbian. I assume you have invested at least one hour for searching for this information on the forum but you failed to find any traces of information about hw crypto acceleration within RK3399? BTW. I don't know the answer. I would also need to search for.
lobster Posted January 26, 2021 Author Posted January 26, 2021 Hi Igor, Yes I have searched the forums and found a few adjacent issues but nothing that answers the question directly. The most relevant seem to be: Arm board with hardware accelerated AES out-of-the-box in Armbian? and rockchip hardware crypto on Tinker Board? Both I think are a little out of date and more or less boil down to (in my reading anyway) "this is probably possible if you build the kernel yourself, but it should be default in later kernels/versions". As far as I can tell there's nothing for anything more recent than ~5.4/5.5. At a base level, though, I'm not even sure I'm checking for the AES ability correctly. Most of the tests I tried come from here and I think they're pretty complete, but hardware AES is new to me. Thanks
Igor Posted January 26, 2021 Posted January 26, 2021 Few more finds: This module should be responsible: https://cateee.net/lkddb/web-lkddb/CRYPTO_DEV_ROCKCHIP.html Enabled (make sure to use latest version, check config in /boot/) https://github.com/armbian/build/blob/master/config/kernel/linux-rockchip64-current.config#L8725 modules built: rk_crypto Chiper is build into so that's why you don't see module: https://github.com/armbian/build/blob/master/config/kernel/linux-rockchip64-current.config#L8634 Comparing numbers: https://github.com/ThomasKaiser/sbc-bench
tparys Posted January 27, 2021 Posted January 27, 2021 (edited) So if I can toss my 2 cents into the ring. I think there's probably two implementations that might be possible here. There's the ARM64 crypto accelerations (which appear in /proc/crypto), and a secure coprocessor which exists on some CPUs. It's my experience that if you care about speed / performance, you want the first one, not the second. Based on the below, your chip has ARM64 crypto extensions. $ grep aes /proc/cpuinfo Features : fp asimd evtstrm aes pmull sha1 sha2 crc32 cpuid ^--- HERE Looking HERE, it looks like they're turned on. And they're built in, so you won't see them is lsmod. CONFIG_CRYPTO_AES_ARM64=y CONFIG_CRYPTO_AES_ARM64_CE=y CONFIG_CRYPTO_AES_ARM64_CE_CCM=y CONFIG_CRYPTO_AES_ARM64_CE_BLK=y CONFIG_CRYPTO_AES_ARM64_NEON_BLK=y OpenSSL's output is expected. Recent builds do not provide special drivers to use HW acceleration. It works this way on other ARM64, such as NVidia Jetson. You can see that the ARM64 / NEON versions were loaded in /proc/crypto. I would also put more faith in the output of "openssl speed aes" and check that you're getting speeds 500+ MB/s. I don't have an RK3399 yet (still on order), so unsure what you'd get. Should you be interested, you can selectively disable OpenSSL HW acceleration, such as AESNI on AMD64 (https://mjanja.ch/2013/11/disabling-aes-ni-on-linux-openssl/). Looks like the environment variable on ARM is OPENSSL_armcap. Never tried playing with it, but it's there if you get bored. And I wouldn't enable the coprocessor support unless you really need it. Those tend to be "secure" rather than "fast". Edit: as an additional example of what you might see, head on over to the sbc bench results HERE, and take a look at the results of the ODroid C2 vs C4. C2 lacks crypto extensions and gets about 44 MB/s AES speed, while the C4 has them and gets closer to 195 MB/s. Obviously a slight difference in max clock rate, but otherwise the same CPU family. Should give you an idea of what you might expect to see. Edited January 27, 2021 by tparys Added sbc bench example
lobster Posted January 28, 2021 Author Posted January 28, 2021 Thanks very much to you both for your thoughtful replies. I also found a somewhat related discussion on the Radxa forums here: OpenVPN performance (same Igor?) In that case the issue was a faulty network cord, but there is a useful detour into this very question. I've also been running some speed tests on different machines I have, and, taken all together with tpary and Igor's points about the kernel config, it appears clear that hardware AES is on by default in Armbian on the RK3399. If anyone finds this thread in the future then I would add that I have some anecdotal evidence that enabling the "rk_crypto" module via "modprobe" might actually cause some instabilities in the system. I HAVE NOT TESTED THIS THOROUGHLY, so please don't take that as a statement of fact. Finally, the sbc bench results linked in tpary's comment are very good. My own numbers are (from "openssl speed -evp aes-256-cbc"): type 16 bytes 64 bytes 256 bytes 1024 bytes 8192 bytes 16384 bytes aes-256-cbc 333423.03k 734862.21k 1010210.68k 1092938.75k 1143302.83k 1138551.47k which is actually ever-so-slightly faster than reported on sbc-bench and much faster than my 3 year old i5, for example. Anyway, thanks so much for all of your help! tl;dr Everything is fine. Hardware AES works out of the box with not fiddling. Let 'em rip!
Recommended Posts