Please enable CRYPTO_ADIANTUM for 5.x kernels

[iustin]

Hi, not sure if this is the proper place, let me know where to report it otherwise.

Using rpi-update I finally got a 5.x kernel (5.4.42-v8+, more precisely), and I was hoping to be able to use the Adiantum cipher for higher dm-crypt speed. However, it seems it's still not available, as:

# zgrep -i adiantum /proc/config.gz
# CONFIG_CRYPTO_ADIANTUM is not set

Furthermore, find /lib/modules/|grep -i adiantum finds nothing at all.

Could you please enable this? The difference in speed from the plain aes (non-accelerated on RPI boards) is quite high, about 3× according to various reports, so this would be useful (it also means 3× lower CPU usage for a given throughput).

Various links about it:

• https://forum.manjaro.org/t/enable-aes-adiantum-for-linux-rpi4-mainline/116038
• https://www.raspberrypi.org/forums/viewtopic.php?t=252980

I also tried to find the actual configs being used, but I'm not familiar with the raspbian build processes (I don't think they're in this repo per se, or at least not as a monolithic config file).

Thanks!

[JamesH65]

Easy enough to build you own kernel. See https://www.raspberrypi.org/documentation/linux/kernel/building.md

Run menuconfig or similar to set the required options.

[JamesH65]

Sorry, suggested that just so you could test it, going to be a while before anything change like this makes it in, and we likely want details on the improvements and any memory/CPU hit.

[iustin]

Thanks for the suggestion, that I can do (although I'm not familiar with rpi kernel builds - why is there no debian package built, would make it so much easier… anyway).

I was however hoping that simply including a new module can be done easily, as it wouldn't get used unless someone actually chooses to use this particular encryption algorithm. So it should be a no-op/safe change to anyone else.

[jfikar]

I'm running custom arm64 kernel 5.4.45 with Adiantum enabled.

CONFIG_CRYPTO_ADIANTUM=m
CRYPTO_NHPOLY1305_NEON=m

The speed on RPi4 is

cryptsetup benchmark -c xchacha20,aes-adiantum
# Tests are approximate using memory only (no storage IO).
#            Algorithm |       Key |      Encryption |      Decryption
xchacha20,aes-adiantum        256b       211.1 MiB/s       214.1 MiB/s


cryptsetup benchmark -c xchacha12,aes-adiantum
# Tests are approximate using memory only (no storage IO).
#            Algorithm |       Key |      Encryption |      Decryption
xchacha12,aes-adiantum        256b       256.6 MiB/s       258.2 MiB/s

While AES gives only

cryptsetup benchmark -c aes-xts -s 256
# Tests are approximate using memory only (no storage IO).
# Algorithm |       Key |      Encryption |      Decryption
    aes-xts        256b        71.0 MiB/s        60.6 MiB/s

Please, enable also the second option I mentioned CRYPTO_NHPOLY1305_NEON, without it the speed is only

cryptsetup benchmark -c xchacha20,aes-adiantum
# Tests are approximate using memory only (no storage IO).
#            Algorithm |       Key |      Encryption |      Decryption
xchacha20,aes-adiantum        256b       127.4 MiB/s       128.6 MiB/s

cryptsetup benchmark -c xchacha12,aes-adiantum
# Tests are approximate using memory only (no storage IO).
#            Algorithm |       Key |      Encryption |      Decryption
xchacha12,aes-adiantum        256b       160.9 MiB/s       160.9 MiB/s

[nebulakl]

I compiled my own armv8 kernel using bcmrpi3_defconfig and enabled the following as per Android Open Source Project's instruction

CONFIG_CRYPTO_ADIANTUM=m
CONFIG_CRYPTO_CHACHA20_NEON=m
CONFIG_CRYPTO_NHPOLY1305_NEON=m

With force_turbo=1 set in config.txt, here's the benchmark result on a Raspberry Pi 3 Model B Plus

cryptsetup benchmark -c xchacha12,aes-adiantum
# Tests are approximate using memory only (no storage IO).
#            Algorithm |       Key |      Encryption |      Decryption
xchacha12,aes-adiantum        256b       138.4 MiB/s       138.5 MiB/s

cryptsetup benchmark -c xchacha20,aes-adiantum
# Tests are approximate using memory only (no storage IO).
#            Algorithm |       Key |      Encryption |      Decryption
xchacha20,aes-adiantum        256b       120.4 MiB/s       120.1 MiB/s

benchmark result using aes-xts, for comparison

cryptsetup benchmark -c aes-xts -s 256
# Tests are approximate using memory only (no storage IO).
# Algorithm |       Key |      Encryption |      Decryption
    aes-xts        256b        63.2 MiB/s        57.0 MiB/s

cryptsetup benchmark -c aes-xts -s 512
# Tests are approximate using memory only (no storage IO).
# Algorithm |       Key |      Encryption |      Decryption
    aes-xts        512b        48.7 MiB/s        43.6 MiB/s

[tyger]

Hi, were there any development of the case?
I wonder, given the benefits of those modules compiled into kernel and low impact on the actual build (as was mentioned, there are no expected impact unless some decide to uses them explicitly), will it help to create pull request adding those configuration params in?

[elpeh]

As asked on the raspberrypi.org forum, I state that I'd deeply support this request.

Thanks, Lutz

[popcornmix]

Posting the size of the kernel.img file and the output of "free" with and without this option would be useful information to help getting this merged.

[iustin]

@popcornmix, are you serious? I ask as this seems a strange question - this is an encryption module, not a config option that impacts anything else outside of it. Unless someone uses it, it doesn't affect free memory, and as long as it's compiled as a module (all other crypto code is), it won't affect the size of kernel.img.

But since you asked, on an amd64 machine:

# lsmod|grep -i adiantum
# free
              total        used        free      shared  buff/cache   available
Mem:       32787828    14331028     3042344      846584    15414456    17146252
Swap:      33554428     1332480    32221948
# modprobe adiantum 
# lsmod|grep -i adiantum
adiantum               16384  0
libpoly1305            16384  1 adiantum
# free
              total        used        free      shared  buff/cache   available
Mem:       32787828    14336644     3036524      846584    15414660    17140636
Swap:      33554428     1332480    32221948

The actual module size seems to be 16KiB of memory, and the free difference is around 6KiB (this is a somewhat busy host though).

I really don't see the reason to be so careful about yet another crypto algorithm, when the 5.4.72 kernel already has 41 modules. Am I missing something specific to Raspberry PIs kernel/OS?

[popcornmix]

@iustin enabling a module can affect the size of the base kernel if it selects other options that aren't modules.

@pelwell happy to add this?

[iustin]

@iustin enabling a module can affect the size of the base kernel if it selects other options that aren't modules.

Ah, in that sense yes, but this is a really small module AFAIK. It's also used, again as far as I know, on most Android phones for which it was written in the first place, so it has real world usage.

[elpeh]

Sorry for asking, but any progress in the decision process?
5.10.0-v7l+ #1382 still doesn't include it.

[viduq]

I also would like to know: Might this issue be considered in the future?

[popcornmix]

@pelwell it selects:

	select CRYPTO_CHACHA20
	select CRYPTO_LIB_POLY1305_GENERIC
	select CRYPTO_MANAGER

which are already enabled, and

	select CRYPTO_NHPOLY1305

which selects:

	select CRYPTO_HASH
	select CRYPTO_LIB_POLY1305_GENERIC

which are already enabled.
So I think the only impact is the adiantum.c file (modestly sized) added as a module.
Seems okay to me.