Harware AES in RockPi4?

[lobster]

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]

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]

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]

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]

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]

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!