linux-arm-kernel.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
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


  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).