Illegal instruction crash in libsodium on Raspberry Pi Armv8

[enclave-alistair]

Hi, me again, afraid I found a different illegal instruction crash, this time on linux-arm64, only on a Raspberry Pi ARMv8.

The libsodium binary is from the nuget package, so was built with:

zig build -Doptimize=ReleaseFast -Dtarget=aarch64-linux-gnu.2.23 -Dcpu=baseline

Currently trying to determine exact crash location, it happens much later in our code than the prior problem on x64, but suspect it's in the ChaChaPoly implementation, or possibly in the AES path if AES support is being incorrectly detected as "supported".

The failing device has the following CPU profile:

processor       : 0
BogoMIPS        : 108.00
Features        : fp asimd evtstrm crc32 cpuid
CPU implementer : 0x41
CPU architecture: 8
CPU variant     : 0x0
CPU part        : 0xd08
CPU revision    : 3

As you can see, clearly no aes flag.

The binary works fine on an ARM64 device with the following profile:

processor       : 0
BogoMIPS        : 50.00
Features        : fp asimd evtstrm aes pmull sha1 sha2 crc32 atomics fphp asimdhp cpuid asimdrdm lrcpc dcpop asimddp
CPU implementer : 0x41
CPU architecture: 8
CPU variant     : 0x3
CPU part        : 0xd0c
CPU revision    : 1

From what I can determine from the libsodium source, the build provided does AES detection at runtime against the CPU flags; we call crypto_aead_aes256gcm_is_available before using AESGCM, falling back to ChaChaPoly. My guess is either that it's continuing down the AES path because crypto_aead_aes256gcm_is_available is returning true unexpectedly, or there's some issue with ChaChaPoly on that CPU.

Any thoughts @jedisct1?

[enclave-alistair]

Just wanted to confirm, now I have a raspberry Pi in front of me, that the build of libsodium provided in the nuget package; i.e. built with:

sudo apt-get install -y qemu binfmt-support qemu-user-static qemu-system-arm gcc-aarch64-linux-gnu libc6-arm64-cross
sudo dpkg --add-architecture arm64
sudo update-binfmts --enable qemu-aarch64
sudo update-binfmts --display
sudo ln -s /usr/aarch64-linux-gnu/lib/ld-linux-aarch64.so.* /lib
zig build -Doptimize=ReleaseFast -Dtarget=aarch64-linux-gnu.2.23 -Dcpu=baseline

Results in a binary that assumes ARM AES is available, even though it is not.

GDB confirms crash occurs in 0x0000007f4a1e03f4 in crypto_aead_aes256gcm_beforenm (), after crypto_aead_aes256gcm_is_available() has returned true.

[enclave-alistair]

From what I can tell, if HAVE_ARMCRYPTO is defined, then __ARM_FEATURE_AES and __ARM_FEATURE_CRYPTO is defined, meaning in runtime.c, cpu_features->has_armcrypto is forced to '1', rather than using the CPU flags to detect it at runtime.

[enclave-alistair]

For any .NET consumers finding this, you can check for AES Cpu flag availability with System.Runtime.Intrinsics.Arm.Aes.IsSupported. I've used this as a second check on top of crypto_aead_aes256gcm_is_available.

[jedisct1]

Should be fixed now, including in stable. Thanks a ton for your report!