From: Harald Freudenberger <freude@linux.ibm.com>
To: Eric Biggers <ebiggers@kernel.org>
Cc: linux-crypto@vger.kernel.org, David Howells <dhowells@redhat.com>,
Ard Biesheuvel <ardb@kernel.org>,
"Jason A . Donenfeld" <Jason@zx2c4.com>,
Holger Dengler <dengler@linux.ibm.com>,
Herbert Xu <herbert@gondor.apana.org.au>,
linux-arm-kernel@lists.infradead.org, linux-s390@vger.kernel.org,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH v2 00/15] SHA-3 library
Date: Thu, 30 Oct 2025 11:10:22 +0100 [thread overview]
Message-ID: <fa8bc10f36b1aeb9ffe1abf6350adbc1@linux.ibm.com> (raw)
In-Reply-To: <20251029163216.GA1603@sol>
On 2025-10-29 17:32, Eric Biggers wrote:
> On Wed, Oct 29, 2025 at 10:30:40AM +0100, Harald Freudenberger wrote:
>> > If the s390 folks could re-test the s390 optimized SHA-3 code (by
>> > enabling CRYPTO_LIB_SHA3_KUNIT_TEST and CRYPTO_LIB_BENCHMARK), that
>> > would be helpful. QEMU doesn't support the instructions it uses. Also,
>> > it would be helpful to provide the benchmark output from just before
>> > "lib/crypto: s390/sha3: Add optimized Keccak function", just after it,
>> > and after "lib/crypto: s390/sha3: Add optimized one-shot SHA-3 digest
>> > functions". Then we can verify that each change is useful.
> [...]
>>
>> Picked this series from your ebiggers repo branch sha3-lib-v2.
>> Build on s390 runs without any complains, no warnings.
>> As recommended I enabled the KUNIT option and also
>> CRYPTO_SELFTESTS_FULL.
>> With an "modprobe tcrypt" I enforced to run the selftests
>> and in parallel I checked that the s390 specific CPACF instructions
>> are really used (can be done with the pai command and check for
>> the KIMD_SHA3_* counters). Also ran some AF-alg tests to verify
>> all the the sha3 hashes and check for thread safety.
>> All this ran without any findings. However there are NO performance
>> related tests involved.
>
> Thanks! Just to confirm, did you actually run the sha3 KUnit test and
> verify that all its test cases passed? That's the most important one.
> It also includes a benchmark, if CONFIG_CRYPTO_LIB_BENCHMARK=y is
> enabled, and I was hoping to see your results from that after each
> change. The results get printed to the kernel log when the test runs.
>
Here it is - as this is a zVM system the benchmark values may show poor
performance.
Oct 30 10:46:44 b3545008.lnxne.boe kernel: KTAP version 1
Oct 30 10:46:44 b3545008.lnxne.boe kernel: 1..1
Oct 30 10:46:44 b3545008.lnxne.boe kernel: KTAP version 1
Oct 30 10:46:44 b3545008.lnxne.boe kernel: # Subtest: sha3
Oct 30 10:46:44 b3545008.lnxne.boe kernel: # module: sha3_kunit
Oct 30 10:46:44 b3545008.lnxne.boe kernel: 1..21
Oct 30 10:46:44 b3545008.lnxne.boe kernel: ok 1
test_hash_test_vectors
Oct 30 10:46:44 b3545008.lnxne.boe kernel: ok 2
test_hash_all_lens_up_to_4096
Oct 30 10:46:44 b3545008.lnxne.boe kernel: ok 3
test_hash_incremental_updates
Oct 30 10:46:44 b3545008.lnxne.boe kernel: ok 4
test_hash_buffer_overruns
Oct 30 10:46:44 b3545008.lnxne.boe kernel: ok 5 test_hash_overlaps
Oct 30 10:46:44 b3545008.lnxne.boe kernel: ok 6
test_hash_alignment_consistency
Oct 30 10:46:44 b3545008.lnxne.boe kernel: ok 7
test_hash_ctx_zeroization
Oct 30 10:46:44 b3545008.lnxne.boe kernel: ok 8
test_hash_interrupt_context_1
Oct 30 10:46:44 b3545008.lnxne.boe kernel: ok 9
test_hash_interrupt_context_2
Oct 30 10:46:44 b3545008.lnxne.boe kernel: ok 10 test_sha3_224_basic
Oct 30 10:46:44 b3545008.lnxne.boe kernel: ok 11 test_sha3_256_basic
Oct 30 10:46:44 b3545008.lnxne.boe kernel: ok 12 test_sha3_384_basic
Oct 30 10:46:44 b3545008.lnxne.boe kernel: ok 13 test_sha3_512_basic
Oct 30 10:46:44 b3545008.lnxne.boe kernel: ok 14 test_shake128_basic
Oct 30 10:46:44 b3545008.lnxne.boe kernel: ok 15 test_shake256_basic
Oct 30 10:46:44 b3545008.lnxne.boe kernel: ok 16 test_shake128_nist
Oct 30 10:46:44 b3545008.lnxne.boe kernel: ok 17 test_shake256_nist
Oct 30 10:46:44 b3545008.lnxne.boe kernel: ok 18
test_shake_all_lens_up_to_4096
Oct 30 10:46:44 b3545008.lnxne.boe kernel: ok 19
test_shake_multiple_squeezes
Oct 30 10:46:44 b3545008.lnxne.boe kernel: ok 20
test_shake_with_guarded_bufs
Oct 30 10:46:44 b3545008.lnxne.boe kernel: # benchmark_hash: len=1:
14 MB/s
Oct 30 10:46:44 b3545008.lnxne.boe kernel: # benchmark_hash: len=16:
109 MB/s
Oct 30 10:46:44 b3545008.lnxne.boe kernel: # benchmark_hash: len=64:
911 MB/s
Oct 30 10:46:44 b3545008.lnxne.boe kernel: # benchmark_hash:
len=127: 1849 MB/s
Oct 30 10:46:44 b3545008.lnxne.boe kernel: # benchmark_hash:
len=128: 1872 MB/s
Oct 30 10:46:44 b3545008.lnxne.boe kernel: # benchmark_hash:
len=200: 2647 MB/s
Oct 30 10:46:44 b3545008.lnxne.boe kernel: # benchmark_hash:
len=256: 3338 MB/s
Oct 30 10:46:44 b3545008.lnxne.boe kernel: # benchmark_hash:
len=511: 5484 MB/s
Oct 30 10:46:44 b3545008.lnxne.boe kernel: # benchmark_hash:
len=512: 5562 MB/s
Oct 30 10:46:44 b3545008.lnxne.boe kernel: # benchmark_hash:
len=1024: 8297 MB/s
Oct 30 10:46:44 b3545008.lnxne.boe kernel: # benchmark_hash:
len=3173: 12625 MB/s
Oct 30 10:46:44 b3545008.lnxne.boe kernel: # benchmark_hash:
len=4096: 11242 MB/s
Oct 30 10:46:44 b3545008.lnxne.boe kernel: # benchmark_hash:
len=16384: 12853 MB/s
Oct 30 10:46:44 b3545008.lnxne.boe kernel: ok 21 benchmark_hash
Oct 30 10:46:44 b3545008.lnxne.boe kernel: # sha3: pass:21 fail:0 skip:0
total:21
Oct 30 10:46:44 b3545008.lnxne.boe kernel: # Totals: pass:21 fail:0
skip:0 total:21
Oct 30 10:46:44 b3545008.lnxne.boe kernel: ok 1 sha3
>> What's a little bit tricky here is that the sha3 lib is statically
>> build into the kernel. So no chance to unload/load this as a module.
>> For sha1 and the sha2 stuff I can understand the need to have this
>> statically enabled in the kernel. Sha3 is only supposed to be
>> available
>> as backup in case of sha2 deficiencies. So I can't see why this is
>> really statically needed.
>
> CONFIG_CRYPTO_LIB_SHA3 is a tristate option. It can be either built-in
> or a loadable module, depending on what other kconfig options select
> it.
> Same as all the other crypto library modules.
I know and see this. However, I am unable to switch this to 'm'. It
seems
like the root cause is that CRYPTO_SHA3='y' and I can't change this to
'm'.
And honestly I am unable to read these dependencies (forgive my
ignorance):
CONFIG_CRYPTO_SHA3:
SHA-3 secure hash algorithms (FIPS 202, ISO/IEC 10118-3)
Symbol: CRYPTO_SHA3 [=y]
Type : tristate
Defined at crypto/Kconfig:1006
Prompt: SHA-3
Depends on: CRYPTO [=y]
Location:
-> Cryptographic API (CRYPTO [=y])
-> Hashes, digests, and MACs
-> SHA-3 (CRYPTO_SHA3 [=y])
Selects: CRYPTO_HASH [=y] && CRYPTO_LIB_SHA3 [=y]
Selected by [y]:
- CRYPTO_JITTERENTROPY [=y] && CRYPTO [=y]
Selected by [n]:
- MODULE_SIG_SHA3_256 [=n] && MODULES [=y] && (MODULE_SIG [=y] ||
IMA_APPRAISE_MODSIG [=n])
- MODULE_SIG_SHA3_384 [=n] && MODULES [=y] && (MODULE_SIG [=y] ||
IMA_APPRAISE_MODSIG [=n])
- MODULE_SIG_SHA3_512 [=n] && MODULES [=y] && (MODULE_SIG [=y] ||
IMA_APPRAISE_MODSIG [=n])
- CRYPTO_DEV_ZYNQMP_SHA3 [=n] && CRYPTO [=y] && CRYPTO_HW [=y] &&
(ZYNQMP_FIRMWARE [=n] || COMPILE_TEST [=n])
- CRYPTO_DEV_STM32_HASH [=n] && CRYPTO [=y] && CRYPTO_HW [=y] &&
(ARCH_STM32 || ARCH_U8500) && HAS_DMA [=y]
- CRYPTO_DEV_SAFEXCEL [=n] && CRYPTO [=y] && CRYPTO_HW [=y] && (OF
[=n] || PCI [=y] || COMPILE_TEST [=n]) && HAS_IOMEM [=y]
>
> - Eric
next prev parent reply other threads:[~2025-10-30 10:11 UTC|newest]
Thread overview: 34+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-10-26 5:50 [PATCH v2 00/15] SHA-3 library Eric Biggers
2025-10-26 5:50 ` [PATCH v2 01/15] crypto: s390/sha3 - Rename conflicting functions Eric Biggers
2025-10-26 5:50 ` [PATCH v2 02/15] crypto: arm64/sha3 - Rename conflicting function Eric Biggers
2025-10-26 5:50 ` [PATCH v2 03/15] lib/crypto: sha3: Add SHA-3 support Eric Biggers
2025-10-26 5:50 ` [PATCH v2 04/15] lib/crypto: sha3: Move SHA3 Iota step mapping into round function Eric Biggers
2025-10-26 5:50 ` [PATCH v2 05/15] lib/crypto: tests: Add SHA3 kunit tests Eric Biggers
2025-10-26 5:50 ` [PATCH v2 06/15] lib/crypto: tests: Add additional SHAKE tests Eric Biggers
2025-10-26 5:50 ` [PATCH v2 07/15] lib/crypto: sha3: Add FIPS cryptographic algorithm self-test Eric Biggers
2025-10-26 5:50 ` [PATCH v2 08/15] crypto: arm64/sha3 - Update sha3_ce_transform() to prepare for library Eric Biggers
2025-10-26 5:50 ` [PATCH v2 09/15] lib/crypto: arm64/sha3: Migrate optimized code into library Eric Biggers
2025-10-26 5:50 ` [PATCH v2 10/15] lib/crypto: s390/sha3: Add optimized Keccak functions Eric Biggers
2025-10-26 5:50 ` [PATCH v2 11/15] lib/crypto: sha3: Support arch overrides of one-shot digest functions Eric Biggers
2025-10-26 5:50 ` [PATCH v2 12/15] lib/crypto: s390/sha3: Add optimized one-shot SHA-3 " Eric Biggers
2025-10-26 5:50 ` [PATCH v2 13/15] crypto: jitterentropy - Use default sha3 implementation Eric Biggers
2025-10-26 5:50 ` [PATCH v2 14/15] crypto: sha3 - Reimplement using library API Eric Biggers
2025-10-26 5:50 ` [PATCH v2 15/15] crypto: s390/sha3 - Remove superseded SHA-3 code Eric Biggers
2025-10-29 9:30 ` [PATCH v2 00/15] SHA-3 library Harald Freudenberger
2025-10-29 16:32 ` Eric Biggers
2025-10-29 20:33 ` Eric Biggers
2025-10-30 8:11 ` Heiko Carstens
2025-10-30 10:16 ` Harald Freudenberger
2025-10-30 10:10 ` Harald Freudenberger [this message]
2025-10-30 17:14 ` Eric Biggers
2025-10-31 14:29 ` Harald Freudenberger
2025-11-04 11:07 ` Harald Freudenberger
2025-11-04 18:27 ` Eric Biggers
2025-11-05 8:16 ` Harald Freudenberger
2025-11-04 11:55 ` Harald Freudenberger
2025-10-30 14:08 ` Ard Biesheuvel
2025-11-03 17:34 ` Eric Biggers
[not found] ` <4188d18bfcc8a64941c5ebd8de10ede2@linux.ibm.com>
2025-11-06 4:33 ` Eric Biggers
2025-11-06 7:22 ` Eric Biggers
2025-11-06 8:54 ` Harald Freudenberger
2025-11-06 19:51 ` Eric Biggers
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=fa8bc10f36b1aeb9ffe1abf6350adbc1@linux.ibm.com \
--to=freude@linux.ibm.com \
--cc=Jason@zx2c4.com \
--cc=ardb@kernel.org \
--cc=dengler@linux.ibm.com \
--cc=dhowells@redhat.com \
--cc=ebiggers@kernel.org \
--cc=herbert@gondor.apana.org.au \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-crypto@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-s390@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).