aboutsummaryrefslogtreecommitdiffstatshomepage
path: root/arch/s390/crypto
AgeCommit message (Collapse)AuthorFilesLines
2026-09-22Merge tag 'v7.3-p5' of git://git.kernel.org/pub/scm/linux/kernel/git/herbert/crypto-2.6Linus Torvalds1-1/+4
Pull crypto fix from Herbert Xu: "This fixes an hmac hashing bug on s390" * tag 'v7.3-p5' of git://git.kernel.org/pub/scm/linux/kernel/git/herbert/crypto-2.6: crypto: s390/hmac - Generate intermediate CV for API partial block handling
2026-09-19crypto: s390/hmac - Generate intermediate CV for API partial block handlingHolger Dengler1-1/+4
The API partial block handling requires a intermediate chaining value (CV). The internal function hash_data() sets the function code correctly, so also call cpacf_kimd() instruction for intermediate CV generation, as cpacf_klmd() always generate the final hash value. Cc: stable@vger.kernel.org # 6.15+ Fixes: 08811169ac01 ("crypto: s390/hmac - Use API partial block handling") Signed-off-by: Holger Dengler <dengler@linux.ibm.com> Reviewed-by: Harald Freudenberger <freude@linux.ibm.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2026-09-08s390/crypto: Enable CONTEXT_ANALYSISHeiko Carstens1-0/+2
Enable CONTEXT_ANALYSIS since s390's crypto code compiles now without warnings. Reviewed-by: Harald Freudenberger <freude@linux.ibm.com> Signed-off-by: Heiko Carstens <hca@linux.ibm.com> Signed-off-by: Vasily Gorbik <gor@linux.ibm.com>
2026-09-08s390/crypto: Map EBUSY to EIO when key conversion fails repeatedlyHarald Freudenberger2-0/+8
When hardware persistently returns -EBUSY after exhausting retries, the error propagates to crypto_finalize_*_request(). The crypto API's completion wrapper treats -EBUSY as a queueing status and swallows it, preventing the completion callback from firing. This causes callers using crypto_wait_req() to block indefinitely. Translate persistent -EBUSY to -EIO after retry exhaustion to ensure proper error propagation and callback invocation. Fixes: 6cd87cb5ef6c ("s390/crypto: Rework protected key AES for true asynch support") Signed-off-by: Harald Freudenberger <freude@linux.ibm.com> Reviewed-by: Holger Dengler <dengler@linux.ibm.com> Cc: stable@vger.kernel.org # 6.16+ Signed-off-by: Heiko Carstens <hca@linux.ibm.com> Signed-off-by: Vasily Gorbik <gor@linux.ibm.com>
2026-09-08s390/crypto: Fix wrong return code to engine in asynch callbacksHarald Freudenberger2-5/+5
When crypto_finalize_hash_request() or crypto_finalize_skcipher_request() explicitly completes a request, the do_one_request callback must return 0 to indicate successful handling. Returning a negative error code causes the crypto engine to assume the driver failed to take ownership and triggers a second completion via crypto_request_complete(), resulting in a double completion. This pattern occurs in paes_s390.c 4 times and once in phmac_s390.c. Fixed in phmac_do_one_request() and all four paes do_one_request callbacks (ecb, cbc, ctr, xts) by returning 0 after explicit finalization instead of propagating the error code. Fixes: 6cd87cb5ef6c ("s390/crypto: Rework protected key AES for true asynch support") Signed-off-by: Harald Freudenberger <freude@linux.ibm.com> Reviewed-by: Holger Dengler <dengler@linux.ibm.com> Cc: stable@vger.kernel.org # 6.16+ Signed-off-by: Heiko Carstens <hca@linux.ibm.com> Signed-off-by: Vasily Gorbik <gor@linux.ibm.com>
2026-09-08s390/crypto: Fix handling of EBUSY in PHMAC when req is pushed to crypto engineHarald Freudenberger1-9/+21
When a request is transferred to the engine via crypto_transfer_hash_request_to_engine() there are two return codes signaling a successful transfer: EINPROGRESS and EBUSY. However the correct handling of EBUSY was missing and has been added as a return code indicating a successful transfer to the crypto engine. Fixes: cbbc675506cc ("crypto: s390 - New s390 specific protected key hash phmac") Signed-off-by: Harald Freudenberger <freude@linux.ibm.com> Reviewed-by: Holger Dengler <dengler@linux.ibm.com> Cc: stable@vger.kernel.org # 6.17+ Signed-off-by: Heiko Carstens <hca@linux.ibm.com> Signed-off-by: Vasily Gorbik <gor@linux.ibm.com>
2026-09-08s390/crypto: Fix handling of EBUSY in PAES when req is pushed to crypto engineHarald Freudenberger1-12/+24
When a request is transferred to the engine via crypto_transfer_skcipher_request_to_engine() there are two return codes signaling a successful transfer: EINPROGRESS and EBUSY. However the correct handling of EBUSY was missing and has been added as a return code indicating a successful transfer to the crypto engine. Fixes: 6cd87cb5ef6c ("s390/crypto: Rework protected key AES for true asynch support") Signed-off-by: Harald Freudenberger <freude@linux.ibm.com> Reviewed-by: Holger Dengler <dengler@linux.ibm.com> Cc: stable@vger.kernel.org # 6.16+ Signed-off-by: Heiko Carstens <hca@linux.ibm.com> Signed-off-by: Vasily Gorbik <gor@linux.ibm.com>
2026-09-08s390/crypto: Fix missing cra_flags in paes_s390Harald Freudenberger1-0/+4
The 4 algorithms implemented in paes_s390 never had any cra_flags set. So add code which sets the cra_flag to CRYPTO_ALG_ASYNC and CRYPTO_ALG_NO_FALLBACK. Fixes: 4ccd065a69df ("crypto: ahash - Add support for drivers with no fallback") Signed-off-by: Harald Freudenberger <freude@linux.ibm.com> Reviewed-by: Holger Dengler <dengler@linux.ibm.com> Cc: stable@vger.kernel.org # 6.17+ Signed-off-by: Heiko Carstens <hca@linux.ibm.com> Signed-off-by: Vasily Gorbik <gor@linux.ibm.com>
2026-09-08s390/crypto: Fix use of mutex in atomic context in PAESHarald Freudenberger1-50/+57
The PAES CTR implementation used a mutex to lock one page of exclusive memory for fast CTR processing. Unfortunately a mutex is not save to use in atomic or interrupt context. So use a binary semaphore instead which is save to use in such environments. Furthermore rework the code to get rid of conditional locking. So restructure the PAES CRT code by extracting the main loop into a separate function and just give in information about the (locked) page can be used or not (is not locked). Fixes: 6cd87cb5ef6c ("s390/crypto: Rework protected key AES for true asynch support") Signed-off-by: Harald Freudenberger <freude@linux.ibm.com> Reviewed-by: Holger Dengler <dengler@linux.ibm.com> Cc: stable@vger.kernel.org # 6.16+ Signed-off-by: Heiko Carstens <hca@linux.ibm.com> Signed-off-by: Vasily Gorbik <gor@linux.ibm.com>
2026-09-08s390/crypto: Fix missing scrub of temp buffers with PAES algorithmHarald Freudenberger1-1/+2
In function ctr_paes_do_crypt() there is a buffer used to process remaining bytes < AES_BLOCK_SIZE. This buffer was not scrubbed and thus could lead to expose of unwanted data. Rework the code to explicitly scrub the buffer at the end of the function to avoid exposure of maybe sensitive data. In function __xts_2keys_prep_param() change the existing scrub to clean the whole param block instead of just the key field. Fixes: 6cd87cb5ef6c ("s390/crypto: Rework protected key AES for true asynch support") Signed-off-by: Harald Freudenberger <freude@linux.ibm.com> Reviewed-by: Holger Dengler <dengler@linux.ibm.com> Cc: stable@vger.kernel.org # 6.16+ Signed-off-by: Heiko Carstens <hca@linux.ibm.com> Signed-off-by: Vasily Gorbik <gor@linux.ibm.com>
2026-09-08s390/crypto: Fix return code handling at skcipher_walk_done in PAES algorithmsHarald Freudenberger1-11/+27
All the 4 PAES cipher processing loops were not checking the return value of skcipher_walk_done() immediately after calling it. This could lead to error masking when both the walk operation failed and a subsequent key conversion was needed (k < n condition). Add immediate error checks after skcipher_walk_done() in all main processing loops (ECB, CBC, CTR, XTS modes) to ensure walk errors are properly propagated and not masked by subsequent operations. With that comes a slight rework around the skcipher_walk_done() invocation. It is now necessary to check if the walk has already been finalized (walk->nbytes is then 0) or not to avoid double de-allocation of resources held by the walk. Fixes: 6cd87cb5ef6c ("s390/crypto: Rework protected key AES for true asynch support") Signed-off-by: Harald Freudenberger <freude@linux.ibm.com> Reviewed-by: Holger Dengler <dengler@linux.ibm.com> Cc: stable@vger.kernel.org # 6.16+ Signed-off-by: Heiko Carstens <hca@linux.ibm.com> Signed-off-by: Vasily Gorbik <gor@linux.ibm.com>
2026-09-08s390/crypto: Fix use of mutex in atomic contextHarald Freudenberger1-24/+39
The AES CTR implementation used a mutex to lock one page of exclusive memory for fast CTR processing. Unfortunately a mutex is not save to use in atomic or interrupt context. So use a binary semaphore instead which is save to use in such environments. Furthermore rework the code to get rid of conditional locking. So restructure the AES CRT code by extracting the main loop into a separate function and just give in information about the (locked) page can be used or not (is not locked). Fixes: 7988fb2c03c8 ("crypto: s390/aes - convert to skcipher API") Suggested-by: Heiko Carstens <hca@linux.ibm.com> Signed-off-by: Harald Freudenberger <freude@linux.ibm.com> Reviewed-by: Holger Dengler <dengler@linux.ibm.com> Cc: stable@vger.kernel.org # 5.5+ Signed-off-by: Heiko Carstens <hca@linux.ibm.com> Signed-off-by: Vasily Gorbik <gor@linux.ibm.com>
2026-09-08s390/crypto: Fix missing scrub of temp buffers with AES ctr and gcm algorithmHarald Freudenberger1-4/+12
In function ctr_aes_crypt() there is a buffer used to process remaining bytes < AES_BLOCK_SIZE. This buffer was not scrubbed and thus could lead to expose of unwanted data. When the buffer is used explicitly scrub it at the end of the code block to avoid exposure of maybe sensitive data. In a similar way the function gcm_aes_crypt() hat an error path where the CPACF param block was not scrubbed. Instead of return early now these error paths go to end of function where explicit scrubbing is done. Similar with the buffers which are part of the gcm_sg_walk structs from the variables gw_in and gw_out. Fixes: d07f951903fa ("crypto: s390/aes - Fix buffer overread in CTR mode") Signed-off-by: Harald Freudenberger <freude@linux.ibm.com> Reviewed-by: Holger Dengler <dengler@linux.ibm.com> Cc: stable@vger.kernel.org # 6.8+ Signed-off-by: Heiko Carstens <hca@linux.ibm.com> Signed-off-by: Vasily Gorbik <gor@linux.ibm.com>
2026-09-08s390/crypto: Fix skcipher_walk return code handling in aes_s390Harald Freudenberger1-6/+6
The return codes from skcipher_walk_virt() were not properly checked before entering the processing loops in ecb_aes_crypt() and ctr_aes_crypt(). If skcipher_walk_virt() fails, the walk structure may be in an undefined state, and attempting to process data could lead to incorrect behavior or accessing uninitialized memory. Add proper return code checking to ensure correct handling of the walk initialization and walk advance and eventually return to the caller with that return code. Fixes: 7988fb2c03c8 ("crypto: s390/aes - convert to skcipher API") Signed-off-by: Harald Freudenberger <freude@linux.ibm.com> Reviewed-by: Holger Dengler <dengler@linux.ibm.com> Cc: stable@vger.kernel.org # 5.5+ Signed-off-by: Heiko Carstens <hca@linux.ibm.com> Signed-off-by: Vasily Gorbik <gor@linux.ibm.com>
2026-08-05s390/crypto: Replace cond_resched() with msleep(1)Peter Zijlstra2-62/+7
With [1] cond_resched() is always compiled away and becomes a no-op. The comments for all cond_resched() calls in crypto code however indicate that the current process should be scheduled away to avoid instant re-invocation of a callback. This is not what cond_resched() would do or did. Instead of just removing the cond_resched() calls, replace them with msleep() calls, as suggested by Holger Dengler. This forces the current task to be scheduled away (sleeps) like originally intended. Holger provided information why this intended [2]: " Let me give a bit of background here: The protected key can only get invalid, if the Linux instance (z/VM or KVM guest) is moved to another hypervisor on a different machine (aka life guest relocation). In such a case, the crypto accelerator card and the host has to exchange the "real key", which is wrapped by the host and handed back to the guest as the re-newed protected key. Unfortunately there is no asynchronous trigger on completion, you have to re-try (and maybe get another "in progress" return). And as if that weren't bad enough, if this key exchange between card and host is the first one, card and host has to instantiate a secure communication channel (including a key exchange for the transport layer). " [1] commit 7dadeaa6e851 ("sched: Further restrict the preemption modes") [2] https://lore.kernel.org/all/39570813-27b0-40f9-89c5-8e2dce05e2f0@linux.ibm.com/ [3] https://lore.kernel.org/all/20260731084027.GE776954@noisy.programming.kicks-ass.net/ [hca@linux.ibm.com: took Peter's patch [3] and provided commit message] Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> Signed-off-by: Heiko Carstens <hca@linux.ibm.com> Reviewed-by: Holger Dengler <dengler@linux.ibm.com> Signed-off-by: Vasily Gorbik <gor@linux.ibm.com>
2026-05-29crypto: s390 - add select CRYPTO_AEAD for aesArnd Bergmann1-0/+1
The aes driver registers both skcipher and aead algorithms, but when aead is not enabled this causes a link failure: s390-linux-ld: arch/s390/crypto/aes_s390.o: in function `aes_s390_fini': arch/s390/crypto/aes_s390.c:969:(.text+0x115e): undefined reference to `crypto_unregister_aead' s390-linux-ld: arch/s390/crypto/aes_s390.o: in function `aes_s390_init': arch/s390/crypto/aes_s390.c:1028:(.init.text+0x294): undefined reference to `crypto_register_aead' Add the missing 'select' statement. Fixes: bf7fa038707c ("s390/crypto: add s390 platform specific aes gcm support.") Signed-off-by: Arnd Bergmann <arnd@arndb.de> Reviewed-by: Harald Freudenberger <freude@linux.ibm.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2026-04-15Merge tag 'v7.1-p1' of git://git.kernel.org/pub/scm/linux/kernel/git/herbert/crypto-2.6Linus Torvalds3-519/+0
Pull crypto update from Herbert Xu: "API: - Replace crypto_get_default_rng with crypto_stdrng_get_bytes - Remove simd skcipher support - Allow algorithm types to be disabled when CRYPTO_SELFTESTS is off Algorithms: - Remove CPU-based des/3des acceleration - Add test vectors for authenc(hmac(md5),cbc({aes,des})) and authenc(hmac({md5,sha1,sha224,sha256,sha384,sha512}),rfc3686(ctr(aes))) - Replace spin lock with mutex in jitterentropy Drivers: - Add authenc algorithms to safexcel - Add support for zstd in qat - Add wireless mode support for QAT GEN6 - Add anti-rollback support for QAT GEN6 - Add support for ctr(aes), gcm(aes), and ccm(aes) in dthev2" * tag 'v7.1-p1' of git://git.kernel.org/pub/scm/linux/kernel/git/herbert/crypto-2.6: (129 commits) crypto: af_alg - use sock_kmemdup in alg_setkey_by_key_serial crypto: vmx - remove CRYPTO_DEV_VMX from Kconfig crypto: omap - convert reqctx buffer to fixed-size array crypto: atmel-sha204a - add Thorsten Blum as maintainer crypto: atmel-ecc - add Thorsten Blum as maintainer crypto: qat - fix IRQ cleanup on 6xxx probe failure crypto: geniv - Remove unused spinlock from struct aead_geniv_ctx crypto: qce - simplify qce_xts_swapiv() crypto: hisilicon - Fix dma_unmap_single() direction crypto: talitos - rename first/last to first_desc/last_desc crypto: talitos - fix SEC1 32k ahash request limitation crypto: jitterentropy - replace long-held spinlock with mutex crypto: hisilicon - remove unused and non-public APIs for qm and sec crypto: hisilicon/qm - drop redundant variable initialization crypto: hisilicon/qm - remove else after return crypto: hisilicon/qm - add const qualifier to info_name in struct qm_cmd_dump_item crypto: hisilicon - fix the format string type error crypto: ccree - fix a memory leak in cc_mac_digest() crypto: qat - add support for zstd crypto: qat - use swab32 macro ...
2026-04-03crypto: s390 - Remove des and des3_ede codeEric Biggers3-519/+0
Since DES and Triple DES are obsolete, there is very little point in maintining architecture-optimized code for them. Remove it. Signed-off-by: Eric Biggers <ebiggers@kernel.org> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2026-03-23lib/crypto: s390/ghash: Migrate optimized code into libraryEric Biggers3-155/+0
Remove the "ghash-s390" crypto_shash algorithm, and replace it with an implementation of ghash_blocks_arch() for the GHASH library. This makes the GHASH library be optimized with CPACF. It also greatly reduces the amount of s390-specific glue code that is needed, and it fixes the issue where this GHASH optimization was disabled by default. Acked-by: Ard Biesheuvel <ardb@kernel.org> Link: https://lore.kernel.org/r/20260319061723.1140720-14-ebiggers@kernel.org Signed-off-by: Eric Biggers <ebiggers@kernel.org>
2026-02-10Merge tag 'v7.0-p1' of git://git.kernel.org/pub/scm/linux/kernel/git/herbert/crypto-2.6Linus Torvalds2-45/+77
Pull crypto update from Herbert Xu: "API: - Fix race condition in hwrng core by using RCU Algorithms: - Allow authenc(sha224,rfc3686) in fips mode - Add test vectors for authenc(hmac(sha384),cbc(aes)) - Add test vectors for authenc(hmac(sha224),cbc(aes)) - Add test vectors for authenc(hmac(md5),cbc(des3_ede)) - Add lz4 support in hisi_zip - Only allow clear key use during self-test in s390/{phmac,paes} Drivers: - Set rng quality to 900 in airoha - Add gcm(aes) support for AMD/Xilinx Versal device - Allow tfms to share device in hisilicon/trng" * tag 'v7.0-p1' of git://git.kernel.org/pub/scm/linux/kernel/git/herbert/crypto-2.6: (100 commits) crypto: img-hash - Use unregister_ahashes in img_{un}register_algs crypto: testmgr - Add test vectors for authenc(hmac(md5),cbc(des3_ede)) crypto: cesa - Simplify return statement in mv_cesa_dequeue_req_locked crypto: testmgr - Add test vectors for authenc(hmac(sha224),cbc(aes)) crypto: testmgr - Add test vectors for authenc(hmac(sha384),cbc(aes)) hwrng: core - use RCU and work_struct to fix race condition crypto: starfive - Fix memory leak in starfive_aes_aead_do_one_req() crypto: xilinx - Fix inconsistant indentation crypto: rng - Use unregister_rngs in register_rngs crypto: atmel - Use unregister_{aeads,ahashes,skciphers} hwrng: optee - simplify OP-TEE context match crypto: ccp - Add sysfs attribute for boot integrity dt-bindings: crypto: atmel,at91sam9g46-sha: add microchip,lan9691-sha dt-bindings: crypto: atmel,at91sam9g46-aes: add microchip,lan9691-aes dt-bindings: crypto: qcom,inline-crypto-engine: document the Milos ICE crypto: caam - fix netdev memory leak in dpaa2_caam_probe crypto: hisilicon/qm - increase wait time for mailbox crypto: hisilicon/qm - obtain the mailbox configuration at one time crypto: hisilicon/qm - remove unnecessary code in qm_mb_write() crypto: hisilicon/qm - move the barrier before writing to the mailbox register ...
2026-01-31crypto: s390/paes - Refuse clear key material by defaultHarald Freudenberger1-36/+57
This patch exploits the new xflag PKEY_XFLAG_NOCLEARKEY from the pkey layer. So now by default all the paes algorithms refuse the use of clear key material ("clear key tokens") in the setkey function with -EINVAL. With a new kernel module parameter "clrkey" this behavior can be controlled. By default clrkey is 'N' but for testing purpose on module load a true value (1, 'Y') may be given to accept clear key tokens. Note that during selftest clear keys are always used and thus the xflag PKEY_XFLAG_NOCLEARKEY is NOT set as long as the algorithm is in a larval state indicated by crypto_skcipher_tested() returning false. Signed-off-by: Harald Freudenberger <freude@linux.ibm.com> Reviewed-by: Holger Dengler <dengler@linux.ibm.com> Reviewed-by: Ingo Franzki <ifranzki@linux.ibm.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2026-01-31crypto: s390/phmac - Refuse clear key material by defaultHarald Freudenberger1-9/+20
This patch exploits the new xflag PKEY_XFLAG_NOCLEARKEY from the pkey layer. So now by default the phmac refuses the use of clear key material ("clear key tokens") in the setkey function with -EINVAL. With a new kernel module parameter "clrkey" this behavior can be controlled. By default clrkey is 'N' but for testing purpose on module load a true value (1, 'Y') may be given to accept clear key tokens. Note that during selftest clear keys are always used and thus the xflag PKEY_XFLAG_NOCLEARKEY is NOT set as long as the algorithm is in a larval state indicated by crypto_ahash_tested() returning false. Signed-off-by: Harald Freudenberger <freude@linux.ibm.com> Reviewed-by: Holger Dengler <dengler@linux.ibm.com> Reviewed-by: Ingo Franzki <ifranzki@linux.ibm.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2026-01-15lib/crypto: s390/aes: Migrate optimized code into libraryEric Biggers2-115/+0
Implement aes_preparekey_arch(), aes_encrypt_arch(), and aes_decrypt_arch() using the CPACF AES instructions. Then, remove the superseded "aes-s390" crypto_cipher. The result is that both the AES library and crypto_cipher APIs use the CPACF AES instructions, whereas previously only crypto_cipher did (and it wasn't enabled by default, which this commit fixes as well). Note that this preserves the optimization where the AES key is stored in raw form rather than expanded form. CPACF just takes the raw key. Acked-by: Ard Biesheuvel <ardb@kernel.org> Tested-by: Holger Dengler <dengler@linux.ibm.com> Reviewed-by: Holger Dengler <dengler@linux.ibm.com> Link: https://lore.kernel.org/r/20260112192035.10427-16-ebiggers@kernel.org Signed-off-by: Eric Biggers <ebiggers@kernel.org>
2025-12-02Merge tag 'libcrypto-updates-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/ebiggers/linuxLinus Torvalds6-504/+0
Pull crypto library updates from Eric Biggers: "This is the main crypto library pull request for 6.19. It includes: - Add SHA-3 support to lib/crypto/, including support for both the hash functions and the extendable-output functions. Reimplement the existing SHA-3 crypto_shash support on top of the library. This is motivated mainly by the upcoming support for the ML-DSA signature algorithm, which needs the SHAKE128 and SHAKE256 functions. But even on its own it's a useful cleanup. This also fixes the longstanding issue where the architecture-optimized SHA-3 code was disabled by default. - Add BLAKE2b support to lib/crypto/, and reimplement the existing BLAKE2b crypto_shash support on top of the library. This is motivated mainly by btrfs, which supports BLAKE2b checksums. With this change, all btrfs checksum algorithms now have library APIs. btrfs is planned to start just using the library directly. This refactor also improves consistency between the BLAKE2b code and BLAKE2s code. And as usual, it also fixes the issue where the architecture-optimized BLAKE2b code was disabled by default. - Add POLYVAL support to lib/crypto/, replacing the existing POLYVAL support in crypto_shash. Reimplement HCTR2 on top of the library. This simplifies the code and improves HCTR2 performance. As usual, it also makes the architecture-optimized code be enabled by default. The generic implementation of POLYVAL is greatly improved as well. - Clean up the BLAKE2s code - Add FIPS self-tests for SHA-1, SHA-2, and SHA-3" * tag 'libcrypto-updates-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/ebiggers/linux: (37 commits) fscrypt: Drop obsolete recommendation to enable optimized POLYVAL crypto: polyval - Remove the polyval crypto_shash crypto: hctr2 - Convert to use POLYVAL library lib/crypto: x86/polyval: Migrate optimized code into library lib/crypto: arm64/polyval: Migrate optimized code into library lib/crypto: polyval: Add POLYVAL library crypto: polyval - Rename conflicting functions lib/crypto: x86/blake2s: Use vpternlogd for 3-input XORs lib/crypto: x86/blake2s: Avoid writing back unchanged 'f' value lib/crypto: x86/blake2s: Improve readability lib/crypto: x86/blake2s: Use local labels for data lib/crypto: x86/blake2s: Drop check for nblocks == 0 lib/crypto: x86/blake2s: Fix 32-bit arg treated as 64-bit lib/crypto: arm, arm64: Drop filenames from file comments lib/crypto: arm/blake2s: Fix some comments crypto: s390/sha3 - Remove superseded SHA-3 code crypto: sha3 - Reimplement using library API crypto: jitterentropy - Use default sha3 implementation lib/crypto: s390/sha3: Add optimized one-shot SHA-3 digest functions lib/crypto: sha3: Support arch overrides of one-shot digest functions ...
2025-12-02Merge tag 's390-6.19-1' of git://git.kernel.org/pub/scm/linux/kernel/git/s390/linuxLinus Torvalds5-10/+5
Pull s390 updates from Heiko Carstens: - Provide a new interface for dynamic configuration and deconfiguration of hotplug memory, allowing with and without memmap_on_memory support. This makes the way memory hotplug is handled on s390 much more similar to other architectures - Remove compat support. There shouldn't be any compat user space around anymore, therefore get rid of a lot of code which also doesn't need to be tested anymore - Add stackprotector support. GCC 16 will get new compiler options, which allow to generate code required for kernel stackprotector support - Merge pai_crypto and pai_ext PMU drivers into a new driver. This removes a lot of duplicated code. The new driver is also extendable and allows to support new PMUs - Add driver override support for AP queues - Rework and extend zcrypt and AP trace events to allow for tracing of crypto requests - Support block sizes larger than 65535 bytes for CCW tape devices - Since the rework of the virtual kernel address space the module area and the kernel image are within the same 4GB area. This eliminates the need of weak per cpu variables. Get rid of ARCH_MODULE_NEEDS_WEAK_PER_CPU - Various other small improvements and fixes * tag 's390-6.19-1' of git://git.kernel.org/pub/scm/linux/kernel/git/s390/linux: (92 commits) watchdog: diag288_wdt: Remove KMSG_COMPONENT macro s390/entry: Use lay instead of aghik s390/vdso: Get rid of -m64 flag handling s390/vdso: Rename vdso64 to vdso s390: Rename head64.S to head.S s390/vdso: Use common STABS_DEBUG and DWARF_DEBUG macros s390: Add stackprotector support s390/modules: Simplify module_finalize() slightly s390: Remove KMSG_COMPONENT macro s390/percpu: Get rid of ARCH_MODULE_NEEDS_WEAK_PER_CPU s390/ap: Restrict driver_override versus apmask and aqmask use s390/ap: Rename mutex ap_perms_mutex to ap_attr_mutex s390/ap: Support driver_override for AP queue devices s390/ap: Use all-bits-one apmask/aqmask for vfio in_use() checks s390/debug: Update description of resize operation s390/syscalls: Switch to generic system call table generation s390/syscalls: Remove system call table pointer from thread_struct s390/uapi: Remove 31 bit support from uapi header files s390: Remove compat support tools: Remove s390 compat support ...
2025-11-24s390: Remove KMSG_COMPONENT macroHeiko Carstens5-10/+5
The KMSG_COMPONENT macro is a leftover of the s390 specific "kernel message catalog" which never made it upstream. Remove the macro in order to get rid of a pointless indirection. Replace all users with the string it defines. In almost all cases this leads to a simple replacement like this: - #define KMSG_COMPONENT "appldata" - #define pr_fmt(fmt) KMSG_COMPONENT ": " fmt + #define pr_fmt(fmt) "appldata: " fmt Except for some special cases this is just mechanical/scripted work. Acked-by: Thomas Richter <tmricht@linux.ibm.com> Signed-off-by: Heiko Carstens <hca@linux.ibm.com>
2025-11-05crypto: s390/sha3 - Remove superseded SHA-3 codeEric Biggers6-504/+0
The SHA-3 library now utilizes the same s390 SHA-3 acceleration capabilities as the arch/s390/crypto/ SHA-3 crypto_shash algorithms. Moreover, crypto/sha3.c now uses the SHA-3 library. The result is that all SHA-3 APIs are now s390-accelerated without any need for the old SHA-3 code in arch/s390/crypto/. Remove this superseded code. Also update the s390 defconfig and debug_defconfig files to enable CONFIG_CRYPTO_SHA3 instead of CONFIG_CRYPTO_SHA3_256_S390 and CONFIG_CRYPTO_SHA3_512_S390. This makes it so that the s390-optimized SHA-3 continues to be built when either of these defconfigs is used. Tested-by: Harald Freudenberger <freude@linux.ibm.com> Reviewed-by: Ard Biesheuvel <ardb@kernel.org> Link: https://lore.kernel.org/r/20251026055032.1413733-16-ebiggers@kernel.org Signed-off-by: Eric Biggers <ebiggers@kernel.org>
2025-11-03crypto: s390/sha3 - Rename conflicting functionsDavid Howells2-10/+10
Rename the s390 sha3_*_init() functions to have an "s390_" prefix to avoid a name conflict with the upcoming SHA-3 library functions. Note: this code will be superseded later. This commit simply keeps the kernel building for the initial introduction of the library. [EB: dropped unnecessary rename of import and export functions, and improved commit message] Signed-off-by: David Howells <dhowells@redhat.com> Tested-by: Harald Freudenberger <freude@linux.ibm.com> Reviewed-by: Ard Biesheuvel <ardb@kernel.org> Link: https://lore.kernel.org/r/20251026055032.1413733-2-ebiggers@kernel.org Signed-off-by: Eric Biggers <ebiggers@kernel.org>
2025-10-23crypto: s390/phmac - Do not modify the req->nbytes valueHarald Freudenberger1-18/+34
The phmac implementation used the req->nbytes field on combined operations (finup, digest) to track the state: with req->nbytes > 0 the update needs to be processed, while req->nbytes == 0 means to do the final operation. For this purpose the req->nbytes field was set to 0 after successful update operation. However, aead uses the req->nbytes field after a successful hash operation to determine the amount of data to en/decrypt. So an implementation must not modify the nbytes field. Fixed by a slight rework on the phmac implementation. There is now a new field async_op in the request context which tracks the (asynch) operation to process. So the 'state' via req->nbytes is not needed any more and now this field is untouched and may be evaluated even after a request is processed by the phmac implementation. Fixes: cbbc675506cc ("crypto: s390 - New s390 specific protected key hash phmac") Reported-by: Ingo Franzki <ifranzki@linux.ibm.com> Signed-off-by: Harald Freudenberger <freude@linux.ibm.com> Tested-by: Ingo Franzki <ifranzki@linux.ibm.com> Reviewed-by: Ingo Franzki <ifranzki@linux.ibm.com> Reviewed-by: Holger Dengler <dengler@linux.ibm.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2025-08-22crypto: hash - Make HASH_MAX_DESCSIZE a bit more obviousHerbert Xu1-1/+7
Move S390_SHA_CTX_SIZE into crypto/hash.h so that the derivation of HASH_MAX_DESCSIZE is less cryptic. Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2025-07-31Merge tag 'v6.17-p1' of git://git.kernel.org/pub/scm/linux/kernel/git/herbert/crypto-2.6Linus Torvalds7-18/+1093
Pull crypto update from Herbert Xu: "API: - Allow hash drivers without fallbacks (e.g., hardware key) Algorithms: - Add hmac hardware key support (phmac) on s390 - Re-enable sha384 in FIPS mode - Disable sha1 in FIPS mode - Convert zstd to acomp Drivers: - Lower priority of qat skcipher and aead - Convert aspeed to partial block API - Add iMX8QXP support in caam - Add rate limiting support for GEN6 devices in qat - Enable telemetry for GEN6 devices in qat - Implement full backlog mode for hisilicon/sec2" * tag 'v6.17-p1' of git://git.kernel.org/pub/scm/linux/kernel/git/herbert/crypto-2.6: (116 commits) crypto: keembay - Use min() to simplify ocs_create_linked_list_from_sg() crypto: hisilicon/hpre - fix dma unmap sequence crypto: qat - make adf_dev_autoreset() static crypto: ccp - reduce stack usage in ccp_run_aes_gcm_cmd crypto: qat - refactor ring-related debug functions crypto: qat - fix seq_file position update in adf_ring_next() crypto: qat - fix DMA direction for compression on GEN2 devices crypto: jitter - replace ARRAY_SIZE definition with header include crypto: engine - remove {prepare,unprepare}_crypt_hardware callbacks crypto: engine - remove request batching support crypto: qat - flush misc workqueue during device shutdown crypto: qat - enable rate limiting feature for GEN6 devices crypto: qat - add compression slice count for rate limiting crypto: qat - add get_svc_slice_cnt() in device data structure crypto: qat - add adf_rl_get_num_svc_aes() in rate limiting crypto: qat - relocate service related functions crypto: qat - consolidate service enums crypto: qat - add decompression service for rate limiting crypto: qat - validate service in rate limiting sysfs api crypto: hisilicon/sec2 - implement full backlog mode for sec ...
2025-07-29Merge tag 's390-6.17-1' of git://git.kernel.org/pub/scm/linux/kernel/git/s390/linuxLinus Torvalds2-0/+2
Pull s390 updates from Alexander Gordeev: - Standardize on the __ASSEMBLER__ macro that is provided by GCC and Clang compilers and replace __ASSEMBLY__ with __ASSEMBLER__ in both uapi and non-uapi headers - Explicitly include <linux/export.h> in architecture and driver files which contain an EXPORT_SYMBOL() and remove the include from the files which do not contain the EXPORT_SYMBOL() - Use the full title of "z/Architecture Principles of Operation" manual and the name of a section where facility bits are listed - Use -D__DISABLE_EXPORTS for files in arch/s390/boot to avoid unnecessary slowing down of the build and confusing external kABI tools that process symtypes data - Print additional unrecoverable machine check information to make the root cause analysis easier - Move cmpxchg_user_key() handling to uaccess library code, since the generated code is large anyway and there is no benefit if it is inlined - Fix a problem when cmpxchg_user_key() is executing a code with a non-default key: if a system is IPL-ed with "LOAD NORMAL", and the previous system used storage keys where the fetch-protection bit was set for some pages, and the cmpxchg_user_key() is located within such page, a protection exception happens - Either the external call or emergency signal order is used to send an IPI to a remote CPU. Use the external order only, since it is at least as good and sometimes even better, than the emergency signal - In case of an early crash the early program check handler prints more or less random value of the last breaking event address, since it is not initialized properly. Copy the last breaking event address from the lowcore to pt_regs to address this - During STP synchronization check udelay() can not be used, since the first CPU modifies tod_clock_base and get_tod_clock_monotonic() might return a non-monotonic time. Instead, busy-loop on other CPUs, while the the first CPU actually handles the synchronization operation - When debugging the early kernel boot using QEMU with the -S flag and GDB attached, skip the decompressor and start directly in kernel - Rename PAI Crypto event 4210 according to z16 and z17 "z/Architecture Principles of Operation" manual - Remove the in-kernel time steering support in favour of the new s390 PTP driver, which allows the kernel clock steered more precisely - Remove a possible false-positive warning in pte_free_defer(), which could be triggered in a valid case KVM guest process is initializing * tag 's390-6.17-1' of git://git.kernel.org/pub/scm/linux/kernel/git/s390/linux: (29 commits) s390/mm: Remove possible false-positive warning in pte_free_defer() s390/stp: Default to enabled s390/stp: Remove leap second support s390/time: Remove in-kernel time steering s390/sclp: Use monotonic clock in sclp_sync_wait() s390/smp: Use monotonic clock in smp_emergency_stop() s390/time: Use monotonic clock in get_cycles() s390/pai_crypto: Rename PAI Crypto event 4210 scripts/gdb/symbols: make lx-symbols skip the s390 decompressor s390/boot: Introduce jump_to_kernel() function s390/stp: Remove udelay from stp_sync_clock() s390/early: Copy last breaking event address to pt_regs s390/smp: Remove conditional emergency signal order code usage s390/uaccess: Merge cmpxchg_user_key() inline assemblies s390/uaccess: Prevent kprobes on cmpxchg_user_key() functions s390/uaccess: Initialize code pages executed with non-default access key s390/skey: Provide infrastructure for executing with non-default access key s390/uaccess: Make cmpxchg_user_key() library code s390/page: Add memory clobber to page_set_storage_key() s390/page: Cleanup page_set_storage_key() inline assemblies ...
2025-07-18crypto: engine - remove request batching supportOvidiu Panait2-2/+2
Remove request batching support from crypto_engine, as there are no drivers using this feature and it doesn't really work that well. Instead of doing batching based on backlog, a more optimal approach would be for the user to handle the batching (similar to how IPsec can hook into GSO to get 64K of data each time or how block encryption can use unit sizes much greater than 4K). Suggested-by: Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by: Ovidiu Panait <ovidiu.panait.oss@gmail.com> Reviewed-by: Horia Geantă <horia.geanta@nxp.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2025-07-14lib/crypto: s390/sha1: Migrate optimized code into libraryEric Biggers3-114/+0
Instead of exposing the s390-optimized SHA-1 code via s390-specific crypto_shash algorithms, instead just implement the sha1_blocks() library function. This is much simpler, it makes the SHA-1 library functions be s390-optimized, and it fixes the longstanding issue where the s390-optimized SHA-1 code was disabled by default. SHA-1 still remains available through crypto_shash, but individual architectures no longer need to handle it. Reviewed-by: Ard Biesheuvel <ardb@kernel.org> Link: https://lore.kernel.org/r/20250712232329.818226-12-ebiggers@kernel.org Signed-off-by: Eric Biggers <ebiggers@kernel.org>
2025-06-30lib/crypto: s390/sha512: Migrate optimized SHA-512 code to libraryEric Biggers3-162/+0
Instead of exposing the s390-optimized SHA-512 code via s390-specific crypto_shash algorithms, instead just implement the sha512_blocks() library function. This is much simpler, it makes the SHA-512 (and SHA-384) library functions be s390-optimized, and it fixes the longstanding issue where the s390-optimized SHA-512 code was disabled by default. SHA-512 still remains available through crypto_shash, but individual architectures no longer need to handle it. Acked-by: Ard Biesheuvel <ardb@kernel.org> Link: https://lore.kernel.org/r/20250630160320.2888-13-ebiggers@kernel.org Signed-off-by: Eric Biggers <ebiggers@kernel.org>
2025-06-30crypto: sha512 - Rename conflicting symbolsEric Biggers1-4/+4
Rename existing functions and structs in architecture-optimized SHA-512 code that had names conflicting with the upcoming library interface which will be added to <crypto/sha2.h>: sha384_init, sha512_init, sha512_update, sha384, and sha512. Note: all affected code will be superseded by later commits that migrate the arch-optimized SHA-512 code into the library. This commit simply keeps the kernel building for the initial introduction of the library. Acked-by: Ard Biesheuvel <ardb@kernel.org> Link: https://lore.kernel.org/r/20250630160320.2888-2-ebiggers@kernel.org Signed-off-by: Eric Biggers <ebiggers@kernel.org>
2025-06-26crypto: s390 - Add selftest support for phmacHarald Freudenberger1-0/+137
Add key preparation code in case of selftest running to the phmac setkey function: As long as crypto_ahash_tested() returns with false, all setkey() invocations are assumed to carry sheer hmac clear key values and thus need some preparation to work with the phmac implementation. Thus it is possible to use the already available hmac test vectors implemented in the testmanager to test the phmac code. When crypto_ahash_tested() returns true (that is after larval state) the phmac code assumes the key material is a blob digestible by the pkey kernel module which converts the blob into a working key for the phmac code. Signed-off-by: Harald Freudenberger <freude@linux.ibm.com> Reviewed-by: Holger Dengler <dengler@linux.ibm.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2025-06-26crypto: s390 - New s390 specific protected key hash phmacHarald Freudenberger2-0/+912
Add support for protected key hmac ("phmac") for s390 arch. With the latest machine generation there is now support for protected key (that is a key wrapped by a master key stored in firmware) hmac for sha2 (sha224, sha256, sha384 and sha512) for the s390 specific CPACF instruction kmac. This patch adds support via 4 new ahashes registered as phmac(sha224), phmac(sha256), phmac(sha384) and phmac(sha512). Co-developed-by: Holger Dengler <dengler@linux.ibm.com> Signed-off-by: Harald Freudenberger <freude@linux.ibm.com> Reviewed-by: Holger Dengler <dengler@linux.ibm.com> Signed-off-by: Holger Dengler <dengler@linux.ibm.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2025-06-17s390: Explicitly include <linux/export.h>Heiko Carstens2-0/+2
Explicitly include <linux/export.h> in files which contain an EXPORT_SYMBOL(). See commit a934a57a42f6 ("scripts/misc-check: check missing #include <linux/export.h> when W=1") for more details. Acked-by: Alexander Gordeev <agordeev@linux.ibm.com> Signed-off-by: Heiko Carstens <hca@linux.ibm.com> Signed-off-by: Alexander Gordeev <agordeev@linux.ibm.com>
2025-06-13crypto: s390/sha3 - Use cpu byte-order when exportingHerbert Xu3-13/+35
The sha3 partial hash on s390 is in little-endian just like the final hash. However the generic implementation produces native or big-endian partial hashes. Make s390 sha3 conform to that by doing the byte-swap on export and import. Reported-by: Ingo Franzki <ifranzki@linux.ibm.com> Fixes: 6f90ba706551 ("crypto: s390/sha3 - Use API partial block handling") Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2025-06-13crypto: s390/hmac - Fix counter in export stateHerbert Xu1-4/+8
The hmac export state needs to be one block-size bigger to account for the ipad. Reported-by: Ingo Franzki <ifranzki@linux.ibm.com> Fixes: 08811169ac01 ("crypto: s390/hmac - Use API partial block handling") Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2025-05-26Merge tag 's390-6.16-1' of git://git.kernel.org/pub/scm/linux/kernel/git/s390/linuxLinus Torvalds1-538/+1269
Pull s390 updates from Heiko Carstens: - Large rework of the protected key crypto code to allow for asynchronous handling without memory allocation - Speed up system call entry/exit path by re-implementing lazy ASCE handling - Add module autoload support for the diag288_wdt watchdog device driver - Get rid of s390 specific strcpy() and strncpy() implementations, and switch all remaining users to strscpy() when possible - Various other small fixes and improvements * tag 's390-6.16-1' of git://git.kernel.org/pub/scm/linux/kernel/git/s390/linux: (51 commits) s390/pci: Serialize device addition and removal s390/pci: Allow re-add of a reserved but not yet removed device s390/pci: Prevent self deletion in disable_slot() s390/pci: Remove redundant bus removal and disable from zpci_release_device() s390/crypto: Extend protected key conversion retry loop s390/pci: Fix __pcilg_mio_inuser() inline assembly s390/ptrace: Always inline regs_get_kernel_stack_nth() and regs_get_register() s390/thread_info: Cleanup header includes s390/extmem: Add workaround for DCSS unload diag s390/crypto: Rework protected key AES for true asynch support s390/cpacf: Rework cpacf_pcc() to return condition code s390/mm: Fix potential use-after-free in __crst_table_upgrade() s390/mm: Add mmap_assert_write_locked() check to crst_table_upgrade() s390/string: Remove strcpy() implementation s390/con3270: Use strscpy() instead of strcpy() s390/boot: Use strspcy() instead of strcpy() s390: Simple strcpy() to strscpy() conversions s390/pkey/crypto: Introduce xflags param for pkey in-kernel API s390/pkey: Provide and pass xflags within pkey and zcrypt layers s390/uv: Remove uv_get_secret_metadata function ...
2025-05-21s390/crypto: Extend protected key conversion retry loopHarald Freudenberger1-2/+5
CI runs show that the protected key conversion retry loop runs into timeout if a master key change was initiated on the addressed crypto resource shortly before the conversion request. This patch extends the retry logic to run in total 5 attempts with increasing delay (200, 400, 800 and 1600 ms) in case of a busy card. Signed-off-by: Harald Freudenberger <freude@linux.ibm.com> Reviewed-by: Ingo Franzki <ifranzki@linux.ibm.com> Signed-off-by: Heiko Carstens <hca@linux.ibm.com>
2025-05-17s390/crypto: Rework protected key AES for true asynch supportHarald Freudenberger1-538/+1266
This is a complete rework of the protected key AES (PAES) implementation. The goal of this rework is to implement the 4 modes (ecb, cbc, ctr, xts) in a real asynchronous fashion: - init(), exit() and setkey() are synchronous and don't allocate any memory. - the encrypt/decrypt functions first try to do the job in a synchronous manner. If this fails, for example the protected key got invalid caused by a guest suspend/resume or guest migration action, the encrypt/decrypt is transferred to an instance of the crypto engine (see below) for asynchronous processing. These postponed requests are then handled by the crypto engine by invoking the do_one_request() callback but may of course again run into a still not converted key or the key is getting invalid. If the key is still not converted, the first thread does the conversion and updates the key status in the transformation context. The conversion is invoked via pkey API with a new flag PKEY_XFLAG_NOMEMALLOC. Note that once there is an active requests enqueued to get async processed via crypto engine, further requests also need to go via crypto engine to keep the request sequence. This patch together with the pkey/zcrypt/AP extensions to support the new PKEY_XFLAG_NOMEMMALOC should toughen the paes crypto algorithms to truly meet the requirements for in-kernel skcipher implementations and the usage patterns for the dm-crypt and dm-integrity layers. Signed-off-by: Harald Freudenberger <freude@linux.ibm.com> Reviewed-by: Holger Dengler <dengler@linux.ibm.com> Acked-by: Herbert Xu <herbert@gondor.apana.org.au> Link: https://lore.kernel.org/r/20250514090955.72370-3-freude@linux.ibm.com Signed-off-by: Heiko Carstens <hca@linux.ibm.com>
2025-05-05crypto: s390/sha512 - Initialise upper counter to zero for sha384Herbert Xu1-8/+9
Initialise the high bit counter to zero in sha384_init. Also change the state initialisation to use ctx->sha512.state instead of ctx->state for consistency. Fixes: 572b5c4682c7 ("crypto: s390/sha512 - Use API partial block handling") Reported-by: Ingo Franzki <ifranzki@linux.ibm.com> Reported-by: Harald Freudenberger <freude@linux.ibm.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2025-05-05crypto: s390/hmac - Use API partial block handlingHerbert Xu1-46/+107
Use the Crypto API partial block handling. Also switch to the generic export format. Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2025-05-05crypto: s390/hmac - Extend hash length counters to 128 bitsHerbert Xu1-11/+14
As sha512 requires 128-bit counters, extend the hash length counters to that length. Previously they were just 32 bits which means that a >4G sha256 hash would be incorrect. Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2025-05-05crypto: s390/sha256 - implement library instead of shashEric Biggers3-155/+0
Instead of providing crypto_shash algorithms for the arch-optimized SHA-256 code, instead implement the SHA-256 library. This is much simpler, it makes the SHA-256 library functions be arch-optimized, and it fixes the longstanding issue where the arch-optimized SHA-256 was disabled by default. SHA-256 still remains available through crypto_shash, but individual architectures no longer need to handle it. Signed-off-by: Eric Biggers <ebiggers@google.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2025-04-30s390/pkey/crypto: Introduce xflags param for pkey in-kernel APIHarald Freudenberger1-3/+3
Add a new parameter xflags to the in-kernel API function pkey_key2protkey(). Currently there is only one flag supported: * PKEY_XFLAG_NOMEMALLOC: If this flag is given in the xflags parameter, the pkey implementation is not allowed to allocate memory but instead should fall back to use preallocated memory or simple fail with -ENOMEM. This flag is for protected key derive within a cipher or similar which must not allocate memory which would cause io operations - see also the CRYPTO_ALG_ALLOCATES_MEMORY flag in crypto.h. The one and only user of this in-kernel API - the skcipher implementations PAES in paes_s390.c set this flag upon request to derive a protected key from the given raw key material. Signed-off-by: Harald Freudenberger <freude@linux.ibm.com> Reviewed-by: Holger Dengler <dengler@linux.ibm.com> Link: https://lore.kernel.org/r/20250424133619.16495-26-freude@linux.ibm.com Signed-off-by: Heiko Carstens <hca@linux.ibm.com>
2025-04-30crypto: s390/sha512 - Fix sha512 state sizeHerbert Xu2-8/+8
The sha512 state size in s390_sha_ctx is out by a factor of 8, fix it so that it stays below HASH_MAX_DESCSIZE. Also fix the state init function which was writing garbage to the state. Luckily this is not actually used for anything other than export. Reported-by: Harald Freudenberger <freude@linux.ibm.com> Fixes: 572b5c4682c7 ("crypto: s390/sha512 - Use API partial block handling") Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>