Re: bswap is slow on SPARC

[Taylor R Campbell <riastradh%NetBSD.org@localhost>]

> Date: Wed, 26 Nov 2025 09:36:13 +0000
> From: Sad Clouds <cryintothebluesky%gmail.com@localhost>
> 
> On Wed, 26 Nov 2025 04:27:00 +0000
> Taylor R Campbell <riastradh%NetBSD.org@localhost> wrote:
> 
> > Code implementing cryptographic primitives is fairly costly, to
> > verify, test, audit, and maintain it: if you make a mistake --
> > especially in a context where there's no opportunity for a noisy
> > failure to interoperate -- it could just silently destroy any
> > security.  That's why it's important to keep the number of primitives
> > low, and risky to adopt nonstandard variants like a big-endian version
> > of standard primitives.
> 
> OK that makes sense. I think OpenSSL seem to have a number of optimised
> variants of AES for SPARC:
> 
> src/crypto/external/bsd/openssl/lib/libcrypto/arch/sparc64/aesfx-sparcv9.S
> src/crypto/external/bsd/openssl/lib/libcrypto/arch/sparc64/aes-sparcv9.S
> src/crypto/external/bsd/openssl/lib/libcrypto/arch/sparc64/aest4-sparcv9.S
> 
> although I'm not sure how viable it would be to port some of those to
> say src/sys/crypto/aes/arch/sparc64 for example. Are these completely
> different and incompatible designs?

aesfx-sparcv9.S and aest4-sparcv9.S rely on hardware AES instructions
in the CPU.  If we support such CPUs we should take advantage of that,
like we do on amd64 (sys/crypto/aes/arch/x86/aes_ni.S) and aarch64
(sys/crypto/aes/arch/arm/aes_armv8_64.S).

aes-sparcv9.S is likely vulnerable to timing side-channel attacks,
because it uses secret-dependent table indices, in contrast to the
bitsliced implementation that we now use in the kernel.  As I recall,
it has some microarchitecture-specific attempts with specific table
layout and prefetches to mitigate the cache-timing side channel, but
these attempts are not particularly confidence-inspiring.  (The
openssl asm is also a pain to audit, maintain, and wire into the
kernel build.)

(This conflict between performance and security in AES is why I
generally advise against its use!  Although Adiantum does use AES, it
is a very small part of the computation (a single AES block per disk
sector) so Adiantum isn't affected much by its performance.)