On Sat, 10 Aug 2024 at 01:13, Eric Biggers <ebiggers@xxxxxxxxxx> wrote:
>
> From: Eric Biggers <ebiggers@xxxxxxxxxx>
>
> 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@xxxxxxxxxx>
I know that this has been queued up already, but for the record:
Reviewed-by: Ard Biesheuvel <ardb@xxxxxxxxxx>
