linux/arch/arm/crypto/aes-cipher.h

/* SPDX-License-Identifier: GPL-2.0-only */
#ifndef ARM_CRYPTO_AES_CIPHER_H
#define ARM_CRYPTO_AES_CIPHER_H

#include <linux/linkage.h>
#include <linux/types.h>

asmlinkage void __aes_arm_encrypt(const u32 rk[], int rounds,
				  const u8 *in, u8 *out);
asmlinkage void __aes_arm_decrypt(const u32 rk[], int rounds,
				  const u8 *in, u8 *out);

#endif /* ARM_CRYPTO_AES_CIPHER_H */
crypto: arm/aes-neonbs - go back to using aes-arm directly In aes-neonbs, instead of going through the crypto API for the parts that the bit-sliced AES code doesn't handle, namely AES-CBC encryption and single-block AES, just call the ARM scalar AES cipher directly. This basically goes back to the original approach that was used before commit b56f5cbc7e08 ("crypto: arm/aes-neonbs - resolve fallback cipher at runtime"). Calling the ARM scalar AES cipher directly is faster, simpler, and avoids any chance of bugs specific to the use of fallback ciphers such as module loading deadlocks which have happened twice. The deadlocks turned out to be fixable in other ways, but there's no need to rely on anything so fragile in the first place. The rationale for the above-mentioned commit was to allow people to choose to use a time-invariant AES implementation for the fallback cipher. There are a couple problems with that rationale, though: - In practice the ARM scalar AES cipher (aes-arm) was used anyway, since it has a higher priority than aes-fixed-time. Users could go out of their way to disable or blacklist aes-arm, or to lower its priority using NETLINK_CRYPTO, but very few users customize the crypto API to this extent. Systems with the ARMv8 Crypto Extensions used aes-ce, but the bit-sliced algorithms are irrelevant on such systems anyway. - Since commit 913a3aa07d16 ("crypto: arm/aes - add some hardening against cache-timing attacks"), the ARM scalar AES cipher is partially hardened against cache-timing attacks. It actually works like aes-fixed-time, in that it disables interrupts and prefetches its lookup table. It does use a larger table than aes-fixed-time, but even so, it is not clear that aes-fixed-time is meaningfully more time-invariant than aes-arm. And of course, the real solution for time-invariant AES is to use a CPU that supports AES instructions. Signed-off-by: Eric Biggers <ebiggers@google.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au> 2024-08-09 23:11:49 +00:00			`/* SPDX-License-Identifier: GPL-2.0-only */`
			`#ifndef ARM_CRYPTO_AES_CIPHER_H`
			`#define ARM_CRYPTO_AES_CIPHER_H`

			`#include <linux/linkage.h>`
			`#include <linux/types.h>`

			`asmlinkage void __aes_arm_encrypt(const u32 rk[], int rounds,`
			`const u8 in, u8 out);`
			`asmlinkage void __aes_arm_decrypt(const u32 rk[], int rounds,`
			`const u8 in, u8 out);`

			`#endif /* ARM_CRYPTO_AES_CIPHER_H */`