Does the SPARC optimized crypto and CRC code actually work?

Does the SPARC optimized crypto and CRC code actually work?

[Eric Biggers]

Hi,

The Linux kernel contains various SPARC crypto opcodes optimized
functions in lib/crypto/sparc/, lib/crc/sparc/, and arch/sparc/crypto/.

As the kernel's crypto and CRC code has been refactored over time, we've
been updating how the SPARC optimized code is integrated accordingly.
However, QEMU doesn't support the SPARC crypto opcodes, which means that
even though I (and maybe others) been running the tests on SPARC kernels
in QEMU, this doesn't actually execute the SPARC optimized code.

So I have to ask: is someone in the SPARC community actually testing
this code regularly?  That includes running all the KUnit tests for
crypto and CRC as well as the traditional crypto self-tests.

If not, then unless QEMU support is forthcoming I'd suggest we drop this
code to avoid issues on SPARC systems.  The generic code is much better
tested and we know that it works on any architecture, including SPARC.
Correctness is the first priority, especially for cryptography.

- Eric

Re: Does the SPARC optimized crypto and CRC code actually work?

[Nathaniel Roach]

On 17/3/26 04:42, Eric Biggers wrote:
> Hi,
>
> The Linux kernel contains various SPARC crypto opcodes optimized
> functions in lib/crypto/sparc/, lib/crc/sparc/, and arch/sparc/crypto/.
>
> As the kernel's crypto and CRC code has been refactored over time, we've
> been updating how the SPARC optimized code is integrated accordingly.
> However, QEMU doesn't support the SPARC crypto opcodes, which means that
> even though I (and maybe others) been running the tests on SPARC kernels
> in QEMU, this doesn't actually execute the SPARC optimized code.
>
> So I have to ask: is someone in the SPARC community actually testing
> this code regularly?  That includes running all the KUnit tests for
> crypto and CRC as well as the traditional crypto self-tests.
>
> If not, then unless QEMU support is forthcoming I'd suggest we drop this
> code to avoid issues on SPARC systems.  The generic code is much better
> tested and we know that it works on any architecture, including SPARC.
> Correctness is the first priority, especially for cryptography.
>
> - Eric
>
I've been testing some of the PCI changes that have come through on my 
T5-2. I'll happily add some tests for the crypto functions, I've just 
got no idea how to do so.

Re: Does the SPARC optimized crypto and CRC code actually work?

[Eric Biggers]

On Tue, Mar 17, 2026 at 10:48:52AM +0800, Nathaniel Roach wrote:
> I've been testing some of the PCI changes that have come through on my T5-2.
> I'll happily add some tests for the crypto functions, I've just got no idea
> how to do so.

Well, try enabling all KUnit tests in lib/crc/ and lib/crypto/, as well
as CONFIG_CRYPTO_SELFTESTS=y and CONFIG_CRYPTO_SELFTESTS_FULL=y.

However, will this be a regular testing run, or only a one-off run?  If
it will only be one-off, we'll quickly be back to where we started.

We need regular testing on either hardware or QEMU.

- Eric

Re: Does the SPARC optimized crypto and CRC code actually work?

[John Paul Adrian Glaubitz]

Hi Eric,

On Tue, 2026-03-17 at 03:45 +0000, Eric Biggers wrote:
> On Tue, Mar 17, 2026 at 10:48:52AM +0800, Nathaniel Roach wrote:
> > I've been testing some of the PCI changes that have come through on my T5-2.
> > I'll happily add some tests for the crypto functions, I've just got no idea
> > how to do so.
> 
> Well, try enabling all KUnit tests in lib/crc/ and lib/crypto/, as well
> as CONFIG_CRYPTO_SELFTESTS=y and CONFIG_CRYPTO_SELFTESTS_FULL=y.
> 
> However, will this be a regular testing run, or only a one-off run?  If
> it will only be one-off, we'll quickly be back to where we started.
> 
> We need regular testing on either hardware or QEMU.

If Nathaniel can test the code from time to time for the time being, we should
already get some coverage. In the near future, we could certainly set up a CI
job if you let me know what infrastructure to use for it.

Please keep in mind that a lot of us are doing this as volunteers and we don't
always have the possibilities to respond to such requests within a short time.

Feel free to use the sparclinux issue tracker if you want to file any requests:

https://github.com/sparclinux/issues/issues

Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer
`. `'   Physicist
  `-    GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Re: Does the SPARC optimized crypto and CRC code actually work?

[Theodore Tso]

How hard would it be to add support for the Sparc crypto accleration
opcodes to QEMU?  Is that something that could be, say, an GSOC or
Outreachy project?

Just a thought,

						- Ted

Re: Does the SPARC optimized crypto and CRC code actually work?

[John Paul Adrian Glaubitz]

Hi Ted,

On Tue, 2026-03-17 at 10:06 -0400, Theodore Tso wrote:
> How hard would it be to add support for the Sparc crypto accleration
> opcodes to QEMU?  Is that something that could be, say, an GSOC or
> Outreachy project?

Good idea. I'll ask someone who has been mentoring QEMU enhancements in the past.

Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer
`. `'   Physicist
  `-    GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Re: Does the SPARC optimized crypto and CRC code actually work?

[Eric Biggers]

On Tue, Mar 17, 2026 at 03:14:50PM +0100, John Paul Adrian Glaubitz wrote:
> Hi Ted,
> 
> On Tue, 2026-03-17 at 10:06 -0400, Theodore Tso wrote:
> > How hard would it be to add support for the Sparc crypto accleration
> > opcodes to QEMU?  Is that something that could be, say, an GSOC or
> > Outreachy project?
> 
> Good idea. I'll ask someone who has been mentoring QEMU enhancements in the past.
> 
> Adrian

FYI, I filed https://github.com/sparclinux/issues/issues/77

- Eric

Re: Does the SPARC optimized crypto and CRC code actually work?

[John Paul Adrian Glaubitz]

Hi Eric,

On Sun, 2026-03-22 at 07:59 -0700, Eric Biggers wrote:
> On Tue, Mar 17, 2026 at 03:14:50PM +0100, John Paul Adrian Glaubitz wrote:
> > Hi Ted,
> > 
> > On Tue, 2026-03-17 at 10:06 -0400, Theodore Tso wrote:
> > > How hard would it be to add support for the Sparc crypto accleration
> > > opcodes to QEMU?  Is that something that could be, say, an GSOC or
> > > Outreachy project?
> > 
> > Good idea. I'll ask someone who has been mentoring QEMU enhancements in the past.
> > 
> > Adrian
> 
> FYI, I filed https://github.com/sparclinux/issues/issues/77

That's a very well crafted bug report! I appreciate the effort and will try to reach
out to the QEMU people and see if we can get something done within GSoC.

@Nathanial: Can you run the crypto tests and report back?

Thanks,
Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer
`. `'   Physicist
  `-    GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Re: Does the SPARC optimized crypto and CRC code actually work?

[Nathaniel Roach]

On 17/3/26 15:16, John Paul Adrian Glaubitz wrote:
> Hi Eric,
>
> On Tue, 2026-03-17 at 03:45 +0000, Eric Biggers wrote:
>> On Tue, Mar 17, 2026 at 10:48:52AM +0800, Nathaniel Roach wrote:
>>> I've been testing some of the PCI changes that have come through on my T5-2.
>>> I'll happily add some tests for the crypto functions, I've just got no idea
>>> how to do so.
>> Well, try enabling all KUnit tests in lib/crc/ and lib/crypto/, as well
>> as CONFIG_CRYPTO_SELFTESTS=y and CONFIG_CRYPTO_SELFTESTS_FULL=y.
>>
>> However, will this be a regular testing run, or only a one-off run?  If
>> it will only be one-off, we'll quickly be back to where we started.
>>
>> We need regular testing on either hardware or QEMU.
> If Nathaniel can test the code from time to time for the time being, we should
> already get some coverage. In the near future, we could certainly set up a CI
> job if you let me know what infrastructure to use for it.
>
> Please keep in mind that a lot of us are doing this as volunteers and we don't
> always have the possibilities to respond to such requests within a short time.
>
> Feel free to use the sparclinux issue tracker if you want to file any requests:
>
> https://github.com/sparclinux/issues/issues
>
> Adrian
I enabled the below options, based on what I could find, in my test config:

CONFIG_CRYPTO_SELFTESTS=y
CONFIG_CRYPTO_SELFTESTS_FULL=y
CONFIG_CRYPTO_ARIA,BLOWFISH,CAMELLIA,CAST5,CAST6,DES,FCRYPT,SERPENT,
   SM4_GENERIC,TWOFISH,CTR=m
CONFIG_CRC_KUNIT_TEST=m
CONFIG_CRC_BENCHMARK=y
CONFIG_CRYPTO_LIB_BENCHMARK=y
CONFIG_DEBUG_MEMORY_INIT=y
CONFIG_KUNIT=m

This is what looks to be the relevant parts of dmesg:

# dmesg | grep -i 'crypt\|rng\|aes\|alg:\|opcode'
[    2.191836] CPU CAPS: [hpc,ima,pause,cbcond,aes,des,kasumi,camellia]
[    7.090965] Using sparc64 crc32c opcode optimized CRC32C implementation
[    7.090974] Using sparc64 sha256 opcode optimized SHA-256/SHA-224 
implementation
[    7.090979] Using sparc64 sha512 opcode optimized SHA-512/SHA-384 
implementation
[    7.235616] alg: full crypto tests enabled.  This is intended for 
developer use only.
[   20.488863] random: crng init done
[   20.525724] n2rng v0.3 (Jan 7, 2017)
[   20.525746] n2rng f029b448: Registered RNG HVAPI major 2 minor 0
[   20.525758] n2rng f029b448: Found multi-unit-capable RNG, units: 2
[   20.526479] aes_sparc64: Using sparc64 aes opcodes optimized AES 
implementation
[   20.527437] des_sparc64: Using sparc64 des opcodes optimized DES 
implementation
[   20.528391] camellia_sparc64: Using sparc64 camellia opcodes 
optimized CAMELLIA implementation
[   20.529874] n2rng f029b448: Selftest passed on unit 0
[   20.532270] n2rng f029b448: Selftest passed on unit 1
[   20.532315] n2rng f029b448: RNG ready

Is this sufficient to know if it's correct, or are more tests needed?

Cheers,
Nathaniel.

Re: Does the SPARC optimized crypto and CRC code actually work?

[Eric Biggers]

On Mon, Mar 23, 2026 at 06:36:52PM +0800, Nathaniel Roach wrote:
> On 17/3/26 15:16, John Paul Adrian Glaubitz wrote:
> > Hi Eric,
> > 
> > On Tue, 2026-03-17 at 03:45 +0000, Eric Biggers wrote:
> > > On Tue, Mar 17, 2026 at 10:48:52AM +0800, Nathaniel Roach wrote:
> > > > I've been testing some of the PCI changes that have come through on my T5-2.
> > > > I'll happily add some tests for the crypto functions, I've just got no idea
> > > > how to do so.
> > > Well, try enabling all KUnit tests in lib/crc/ and lib/crypto/, as well
> > > as CONFIG_CRYPTO_SELFTESTS=y and CONFIG_CRYPTO_SELFTESTS_FULL=y.
> > > 
> > > However, will this be a regular testing run, or only a one-off run?  If
> > > it will only be one-off, we'll quickly be back to where we started.
> > > 
> > > We need regular testing on either hardware or QEMU.
> > If Nathaniel can test the code from time to time for the time being, we should
> > already get some coverage. In the near future, we could certainly set up a CI
> > job if you let me know what infrastructure to use for it.
> > 
> > Please keep in mind that a lot of us are doing this as volunteers and we don't
> > always have the possibilities to respond to such requests within a short time.
> > 
> > Feel free to use the sparclinux issue tracker if you want to file any requests:
> > 
> > https://github.com/sparclinux/issues/issues
> > 
> > Adrian
> I enabled the below options, based on what I could find, in my test config:
> 
> CONFIG_CRYPTO_SELFTESTS=y
> CONFIG_CRYPTO_SELFTESTS_FULL=y
> CONFIG_CRYPTO_ARIA,BLOWFISH,CAMELLIA,CAST5,CAST6,DES,FCRYPT,SERPENT,
>   SM4_GENERIC,TWOFISH,CTR=m
> CONFIG_CRC_KUNIT_TEST=m
> CONFIG_CRC_BENCHMARK=y
> CONFIG_CRYPTO_LIB_BENCHMARK=y
> CONFIG_DEBUG_MEMORY_INIT=y
> CONFIG_KUNIT=m

I recommend using the latest linux-next, to get the latest KUnit-related
kconfig updates, and using the following on top of sparc64_defconfig:

(
    cat lib/{crc,crypto}/.kunitconfig
    echo CONFIG_EXPERT=y
    echo CONFIG_CRYPTO=y
    echo CONFIG_CRYPTO_SELFTESTS=y
    echo CONFIG_CRYPTO_SELFTESTS_FULL=y
    echo CONFIG_CRYPTO_DES_SPARC64=y
    echo CONFIG_CRYPTO_AES_SPARC64=y
    echo CONFIG_CRYPTO_CAMELLIA_SPARC64=y
    echo CONFIG_CRYPTO_AES=y
    echo CONFIG_CRYPTO_DES=y
    echo CONFIG_CRYPTO_CAMELLIA=y
    echo CONFIG_CRYPTO_ECB=y
    echo CONFIG_CRYPTO_CBC=y
    echo CONFIG_CRYPTO_CTR=y
) >> .config

Note: most of the complexity here is to fully enable the traditional
crypto self-tests to cover arch/sparc/crypto/.  The plan is to finish
migrating those into lib/crypto/, in which case that code will become
covered by the lib/crypto/ tests and only the kunitconfigs would be
needed.  But for now, the traditional tests are still needed too.

- Eric