[PATCH] crypto: arm/aes-neonbs - go back to using aes-arm directly

[Ard Biesheuvel]

On Sat, 10 Aug 2024 at 01:13, Eric Biggers <ebiggers at kernel.org> wrote:
>
> From: Eric Biggers <ebiggers at google.com>
>
> 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 at google.com>

I know that this has been queued up already, but for the record:

Reviewed-by: Ard Biesheuvel <ardb at kernel.org>