Does the SPARC optimized crypto and CRC code actually work?

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.

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

Hi Eric,

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

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

Hi Ted,

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

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

- Eric

Hi Eric,

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

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.

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