summaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2025-07-07crypto: ccp - Fix locking on alloc failure handlingAlexey Kardashevskiy
The __snp_alloc_firmware_pages() helper allocates pages in the firmware state (alloc + rmpupdate). In case of failed rmpupdate, it tries reclaiming pages with already changed state. This requires calling the PSP firmware and since there is sev_cmd_mutex to guard such calls, the helper takes a "locked" parameter so specify if the lock needs to be held. Most calls happen from snp_alloc_firmware_page() which executes without the lock. However commit 24512afa4336 ("crypto: ccp: Handle the legacy TMR allocation when SNP is enabled") switched sev_fw_alloc() from alloc_pages() (which does not call the PSP) to __snp_alloc_firmware_pages() (which does) but did not account for the fact that sev_fw_alloc() is called from __sev_platform_init_locked() (via __sev_platform_init_handle_tmr()) and executes with the lock held. Add a "locked" parameter to __snp_alloc_firmware_pages(). Make sev_fw_alloc() use the new parameter to prevent potential deadlock in rmp_mark_pages_firmware() if rmpupdate() failed. Fixes: 24512afa4336 ("crypto: ccp: Handle the legacy TMR allocation when SNP is enabled") Signed-off-by: Alexey Kardashevskiy <aik@amd.com> Reviewed-by: Tom Lendacky <thomas.lendacky@amd.com> Reviewed-by: Pratik R. Sampat <prsampat@amd.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2025-06-26crypto: testmgr - Enable phmac selftestHarald Freudenberger
Add phmac selftest invocation to the crypto testmanager. Signed-off-by: Harald Freudenberger <freude@linux.ibm.com> Acked-by: Holger Dengler <dengler@linux.ibm.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2025-06-26crypto: s390 - Add selftest support for phmacHarald Freudenberger
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: ahash - Add crypto_ahash_tested() helper functionHarald Freudenberger
Add a little inline helper function crypto_ahash_tested() to the internal/hash.h header file to retrieve the tested status (that is the CRYPTO_ALG_TESTED bit in the cra_flags). Signed-off-by: Harald Freudenberger <freude@linux.ibm.com> Suggested-by: Herbert Xu <herbert@gondor.apana.org.au> 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 Freudenberger
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-26s390/crypto: Add protected key hmac subfunctions for KMACHolger Dengler
The CPACF KMAC instruction supports new subfunctions for protected key hmac. Add defines for these 4 new subfuctions. Signed-off-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: Herbert Xu <herbert@gondor.apana.org.au>
2025-06-26crypto: ahash - make hash walk functions from ahash.c publicHarald Freudenberger
Make the hash walk functions crypto_hash_walk_done() crypto_hash_walk_first() crypto_hash_walk_last() public again. These functions had been removed from the header file include/crypto/internal/hash.h with commit 7fa481734016 ("crypto: ahash - make hash walk functions private to ahash.c") as there was no crypto algorithm code using them. With the upcoming crypto implementation for s390 phmac these functions will be exploited and thus need to be public within the kernel again. Signed-off-by: Harald Freudenberger <freude@linux.ibm.com> Acked-by: Holger Dengler <dengler@linux.ibm.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2025-06-26crypto: aspeed - Fix hash fallback path typoHerbert Xu
Fix typo in the fallback code path. Reported-by: kernel test robot <lkp@intel.com> Closes: https://lore.kernel.org/oe-kbuild-all/202506231830.us4hiwlZ-lkp@intel.com/ Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2025-06-23crypto: hisilicon - Use fine grained DMA mapping directionZenghui Yu
The following splat was triggered when booting the kernel built with arm64's defconfig + CRYPTO_SELFTESTS + DMA_API_DEBUG. ------------[ cut here ]------------ DMA-API: hisi_sec2 0000:75:00.0: cacheline tracking EEXIST, overlapping mappings aren't supported WARNING: CPU: 24 PID: 1273 at kernel/dma/debug.c:596 add_dma_entry+0x248/0x308 Call trace: add_dma_entry+0x248/0x308 (P) debug_dma_map_sg+0x208/0x3e4 __dma_map_sg_attrs+0xbc/0x118 dma_map_sg_attrs+0x10/0x24 hisi_acc_sg_buf_map_to_hw_sgl+0x80/0x218 [hisi_qm] sec_cipher_map+0xc4/0x338 [hisi_sec2] sec_aead_sgl_map+0x18/0x24 [hisi_sec2] sec_process+0xb8/0x36c [hisi_sec2] sec_aead_crypto+0xe4/0x264 [hisi_sec2] sec_aead_encrypt+0x14/0x20 [hisi_sec2] crypto_aead_encrypt+0x24/0x38 test_aead_vec_cfg+0x480/0x7e4 test_aead_vec+0x84/0x1b8 alg_test_aead+0xc0/0x498 alg_test.part.0+0x518/0x524 alg_test+0x20/0x64 cryptomgr_test+0x24/0x44 kthread+0x130/0x1fc ret_from_fork+0x10/0x20 ---[ end trace 0000000000000000 ]--- DMA-API: Mapped at: debug_dma_map_sg+0x234/0x3e4 __dma_map_sg_attrs+0xbc/0x118 dma_map_sg_attrs+0x10/0x24 hisi_acc_sg_buf_map_to_hw_sgl+0x80/0x218 [hisi_qm] sec_cipher_map+0xc4/0x338 [hisi_sec2] This occurs in selftests where the input and the output scatterlist point to the same underlying memory (e.g., when tested with INPLACE_TWO_SGLISTS mode). The problem is that the hisi_sec2 driver maps these two different scatterlists using the DMA_BIDIRECTIONAL flag which leads to overlapped write mappings which are not supported by the DMA layer. Fix it by using the fine grained and correct DMA mapping directions. While at it, switch the DMA directions used by the hisi_zip driver too. Signed-off-by: Zenghui Yu <yuzenghui@huawei.com> Reviewed-by: Longfang Liu <liulongfang@huawei.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2025-06-23crypto: ccree - Don't use %pK through printkThomas Weißschuh
In the past %pK was preferable to %p as it would not leak raw pointer values into the kernel log. Since commit ad67b74d2469 ("printk: hash addresses printed with %p") the regular %p has been improved to avoid this issue. Furthermore, restricted pointers ("%pK") were never meant to be used through printk(). They can still unintentionally leak raw pointers or acquire sleeping locks in atomic contexts. Switch to the regular pointer formatting which is safer and easier to reason about. Signed-off-by: Thomas Weißschuh <thomas.weissschuh@linutronix.de> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2025-06-23crypto: testmgr - Restore sha384 and hmac_sha384 drbgs in FIPS modeJeff Barnes
Set .fips_allowed in the following drbg alg_test_desc structs. drbg_nopr_hmac_sha384 drbg_nopr_sha384 drbg_pr_hmac_sha384 drbg_pr_sha384 The sha384 and hmac_sha384 DRBGs with and without prediction resistance were disallowed in an early version of the FIPS 140-3 Implementation Guidance document. Hence, the fips_allowed flag in struct alg_test_desc pertaining to the affected DRBGs was unset. The IG has been withdrawn and they are allowed again. Furthermore, when the DRBGs are configured, /proc/crypto shows that drbg_*pr_sha384 and drbg_*pr_hmac_sha384 are fips-approved ("fips: yes") but because their self-tests are not run (a consequence of unsetting the fips_allowed flag), the drbgs won't load successfully with the seeming contradictory "fips: yes" in /proc/crypto. This series contains a single patch that sets the fips_allowed flag in the sha384-impacted DRBGs, which restores the ability to load them in FIPS mode. Link: https://lore.kernel.org/linux-crypto/979f4f6f-bb74-4b93-8cbf-6ed653604f0e@jvdsn.com/ Link: https://csrc.nist.gov/CSRC/media/Projects/cryptographic-module-validation-program/documents/fips%20140-3/FIPS%20140-3%20IG.pdf To: Herbert Xu <herbert@gondor.apana.org.au> To: David S. Miller <davem@davemloft.net> Cc: linux-crypto@vger.kernel.org Cc: linux-kernel@vger.kernel.org Signed-off-by: Jeff Barnes <jeffbarnes@linux.microsoft.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2025-06-23crypto: qat - restore ASYM service support for GEN6 devicesSuman Kumar Chakraborty
Support for asymmetric crypto services was not included in the qat_6xxx by explicitly setting the asymmetric capabilities to 0 to allow for additional testing. Enable asymmetric crypto services on QAT GEN6 devices by setting the appropriate capability flags. Fixes: 17fd7514ae68 ("crypto: qat - add qat_6xxx driver") Signed-off-by: Suman Kumar Chakraborty <suman.kumar.chakraborty@intel.com> Reviewed-by: Giovanni Cabiddu <giovanni.cabiddu@intel.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2025-06-23crypto: qat - remove duplicate masking for GEN6 devicesSuman Kumar Chakraborty
The ICP_ACCEL_CAPABILITIES_CIPHER capability is masked out redundantly for QAT GEN6 devices. Remove it to avoid code duplication. This does not introduce any functional change. Signed-off-by: Suman Kumar Chakraborty <suman.kumar.chakraborty@intel.com> Reviewed-by: Giovanni Cabiddu <giovanni.cabiddu@intel.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2025-06-23crypto: ccp - Fix SNP panic notifier unregistrationAshish Kalra
Panic notifiers are invoked with RCU read lock held and when the SNP panic notifier tries to unregister itself from the panic notifier callback itself it causes a deadlock as notifier unregistration does RCU synchronization. Code flow for SNP panic notifier: snp_shutdown_on_panic() -> __sev_firmware_shutdown() -> __sev_snp_shutdown_locked() -> atomic_notifier_chain_unregister(.., &snp_panic_notifier) Fix SNP panic notifier to unregister itself during SNP shutdown only if panic is not in progress. Reviewed-by: Tom Lendacky <thomas.lendacky@amd.com> Cc: stable@vger.kernel.org Fixes: 19860c3274fb ("crypto: ccp - Register SNP panic notifier only if SNP is enabled") Signed-off-by: Ashish Kalra <ashish.kalra@amd.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2025-06-23crypto: zstd - convert to acompSuman Kumar Chakraborty
Convert the implementation to a native acomp interface using zstd streaming APIs, eliminating the need for buffer linearization. This includes: - Removal of the scomp interface in favor of acomp - Refactoring of stream allocation, initialization, and handling for both compression and decompression using Zstandard streaming APIs - Replacement of crypto_register_scomp() with crypto_register_acomp() for module registration Signed-off-by: Suman Kumar Chakraborty <suman.kumar.chakraborty@intel.com> Reviewed-by: Giovanni Cabiddu <giovanni.cabiddu@intel.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2025-06-23crypto: virtio - Remove unused virtcrypto functionsDr. David Alan Gilbert
virtcrypto_devmgr_get_first() and virtcrypto_dev_in_use() were added in 2016 by commit dbaf0624ffa5 ("crypto: add virtio-crypto driver") but have remained unused. Remove them. Signed-off-by: Dr. David Alan Gilbert <linux@treblig.org> Reviewed-by: Zenghui Yu <yuzenghui@huawei.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2025-06-23crypto: qat - lower priority for skcipher and aead algorithmsGiovanni Cabiddu
Most kernel applications utilizing the crypto API operate synchronously and on small buffer sizes, therefore do not benefit from QAT acceleration. Reduce the priority of QAT implementations for both skcipher and aead algorithms, allowing more suitable alternatives to be selected by default. Signed-off-by: Giovanni Cabiddu <giovanni.cabiddu@intel.com> Link: https://lore.kernel.org/all/20250613012357.GA3603104@google.com/ Cc: stable@vger.kernel.org Acked-by: Eric Biggers <ebiggers@kernel.org> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2025-06-23crypto: ahash - Stop legacy tfms from using the set_virt fallback pathHerbert Xu
Ensure that drivers that have not been converted to the ahash API do not use the ahash_request_set_virt fallback path as they cannot use the software fallback. Reported-by: Eric Biggers <ebiggers@kernel.org> Fixes: 9d7a0ab1c753 ("crypto: ahash - Handle partial blocks in API") Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2025-06-23dt-bindings: crypto: Convert ti,omap4-des to DT schemaRob Herring (Arm)
Convert the TI OMAP DES binding to DT schema format. Drop "ti,hwmods" as it is not actually used for this binding. Only OMAP2 platforms are using it. Signed-off-by: Rob Herring (Arm) <robh@kernel.org> Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2025-06-23dt-bindings: crypto: Convert ti,omap2-aes to DT schemaRob Herring (Arm)
Convert the TI OMAP AES binding to DT schema format. It's a straight forward conversion. Make "ti,hwmods" not required as it is deprecated and only used on OMAP2. Signed-off-by: Rob Herring (Arm) <robh@kernel.org> Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2025-06-23crypto: atmel - add support for AES and SHA IPs available on sama7d65 SoCRyan Wanner
This patch adds support for hardware version of AES and SHA IPs available on SAMA7D65 SoC. Signed-off-by: Ryan Wanner <Ryan.Wanner@microchip.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2025-06-23dt-bindings: rng: atmel,at91-trng: add sama7d65 TRNGRyan Wanner
Add compatible for Microchip SAMA7D65 SoC TRNG. Signed-off-by: Ryan Wanner <Ryan.Wanner@microchip.com> Reviewed-by: Claudiu Beznea <claudiu.beznea@tuxon.dev> Acked-by: Rob Herring (Arm) <robh@kernel.org> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2025-06-23dt-bindings: crypto: add sama7d65 in Atmel TDESRyan Wanner
Add DT bindings for SAMA7D65 SoC Atmel TDES. The SAMA7D65 SoC has the same capability as the SAM9x75 SoC. Signed-off-by: Ryan Wanner <Ryan.Wanner@microchip.com> Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2025-06-23dt-bindings: crypto: add sama7d65 in Atmel SHARyan Wanner
Add DT bindings for SAMA7D65 SoC Atmel SHA. The SAMA7D65 similar to the SAM9x75 SoC supports SHA1/224/256/384/512 and supports HMAC for the same hashes. They both also support automatic padding as well as double buffering. Signed-off-by: Ryan Wanner <Ryan.Wanner@microchip.com> Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2025-06-23dt-bindings: crypto: add sama7d65 in Atmel AESRyan Wanner
Add DT bindings for SAMA7D65 SoC in atmel AES. The SAMA7D65 similar to the SAM9x75 SoC supports HMAC, dual buffer, and GCM. And similar all 3 it supports CBC, CFB, CTR, ECB, and XTS. Signed-off-by: Ryan Wanner <Ryan.Wanner@microchip.com> Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2025-06-23dt-bindings: crypto: fsl,sec-v4.0: Add power domains for iMX8QM and iMX8QXPJohn Ernberg
NXP SoCs like the iMX8QM, iMX8QXP or iMX8DXP use power domains for resource management. Add compatible strings for these SoCs (QXP and DXP gets to share as their only difference is a core-count, Q=Quad core and D=Dual core), and allow power-domains for them only. Keep the old restriction for others. Signed-off-by: John Ernberg <john.ernberg@actia.se> Reviewed-by: Rob Herring (Arm) <robh@kernel.org> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2025-06-23crypto: caam - Support iMX8QXP and variants thereofJohn Ernberg
The iMX8QXP (and variants such as the QX, DX, DXP) all identify as iMX8QXP. They have the exact same restrictions as the supported iMX8QM introduced at commit 61bb8db6f682 ("crypto: caam - Add support for i.MX8QM") Loosen the check a little bit with a wildcard to also match the iMX8QXP and its variants. Signed-off-by: John Ernberg <john.ernberg@actia.se> Reviewed-by: Frank Li <Frank.Li@nxp.com> Reviewed-by: Peng Fan <peng.fan@nxp.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2025-06-23crypto: caam - Prevent crash on suspend with iMX8QM / iMX8ULPJohn Ernberg
Since the CAAM on these SoCs is managed by another ARM core, called the SECO (Security Controller) on iMX8QM and Secure Enclave on iMX8ULP, which also reserves access to register page 0 suspend operations cannot touch this page. This is similar to when running OPTEE, where OPTEE will reserve page 0. Track this situation using a new state variable no_page0, reflecting if page 0 is reserved elsewhere, either by other management cores in SoC or by OPTEE. Replace the optee_en check in suspend/resume with the new check. optee_en cannot go away as it's needed elsewhere to gate OPTEE specific situations. Fixes the following splat at suspend: Internal error: synchronous external abort: 0000000096000010 [#1] SMP Hardware name: Freescale i.MX8QXP ACU6C (DT) pstate: 60400005 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : readl+0x0/0x18 lr : rd_reg32+0x18/0x3c sp : ffffffc08192ba20 x29: ffffffc08192ba20 x28: ffffff8025190000 x27: 0000000000000000 x26: ffffffc0808ae808 x25: ffffffc080922338 x24: ffffff8020e89090 x23: 0000000000000000 x22: ffffffc080922000 x21: ffffff8020e89010 x20: ffffffc080387ef8 x19: ffffff8020e89010 x18: 000000005d8000d5 x17: 0000000030f35963 x16: 000000008f785f3f x15: 000000003b8ef57c x14: 00000000c418aef8 x13: 00000000f5fea526 x12: 0000000000000001 x11: 0000000000000002 x10: 0000000000000001 x9 : 0000000000000000 x8 : ffffff8025190870 x7 : ffffff8021726880 x6 : 0000000000000002 x5 : ffffff80217268f0 x4 : ffffff8021726880 x3 : ffffffc081200000 x2 : 0000000000000001 x1 : ffffff8020e89010 x0 : ffffffc081200004 Call trace: readl+0x0/0x18 caam_ctrl_suspend+0x30/0xdc dpm_run_callback.constprop.0+0x24/0x5c device_suspend+0x170/0x2e8 dpm_suspend+0xa0/0x104 dpm_suspend_start+0x48/0x50 suspend_devices_and_enter+0x7c/0x45c pm_suspend+0x148/0x160 state_store+0xb4/0xf8 kobj_attr_store+0x14/0x24 sysfs_kf_write+0x38/0x48 kernfs_fop_write_iter+0xb4/0x178 vfs_write+0x118/0x178 ksys_write+0x6c/0xd0 __arm64_sys_write+0x14/0x1c invoke_syscall.constprop.0+0x64/0xb0 do_el0_svc+0x90/0xb0 el0_svc+0x18/0x44 el0t_64_sync_handler+0x88/0x124 el0t_64_sync+0x150/0x154 Code: 88dffc21 88dffc21 5ac00800 d65f03c0 (b9400000) Fixes: d2835701d93c ("crypto: caam - i.MX8ULP donot have CAAM page0 access") Cc: stable@kernel.org # v6.10+ Signed-off-by: John Ernberg <john.ernberg@actia.se> Reviewed-by: Peng Fan <peng.fan@nxp.com> Reviewed-by: Frank Li <Frank.Li@nxp.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2025-06-23crypto: x86 - Fix build warnings about export.hChengZhenghan
I got some build warnings with W=1: arch/x86/coco/sev/core.c: arch/x86/crypto/aria_aesni_avx2_glue.c: warning: EXPORT_SYMBOL() is used, but #include <linux/export.h> is missing arch/x86/crypto/aria_aesni_avx_glue.c: warning: EXPORT_SYMBOL() is used, but #include <linux/export.h> is missing arch/x86/crypto/camellia_aesni_avx_glue.c: warning: EXPORT_SYMBOL() is used, but #include <linux/export.h> is missing arch/x86/crypto/camellia_glue.c: warning: EXPORT_SYMBOL() is used, but #include <linux/export.h> is missing arch/x86/crypto/curve25519-x86_64.c: warning: EXPORT_SYMBOL() is used, but #include <linux/export.h> is missing arch/x86/crypto/serpent_avx_glue.c: warning: EXPORT_SYMBOL() is used, but #include <linux/export.h> is missing arch/x86/crypto/sm4_aesni_avx_glue.c: warning: EXPORT_SYMBOL() is used, but #include <linux/export.h> is missing arch/x86/crypto/twofish_glue.c: warning: EXPORT_SYMBOL() is used, but #include <linux/export.h> is missing arch/x86/crypto/twofish_glue_3way.c: warning: EXPORT_SYMBOL() is used, but #include <linux/export.h> is missing so I fixed these build warnings for x86_64. Signed-off-by: ChengZhenghan <chengzhenghan@uniontech.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2025-06-23crypto: arm/aes-neonbs - work around gcc-15 warningArnd Bergmann
I get a very rare -Wstringop-overread warning with gcc-15 for one function in aesbs_ctr_encrypt(): arch/arm/crypto/aes-neonbs-glue.c: In function 'ctr_encrypt': arch/arm/crypto/aes-neonbs-glue.c:212:1446: error: '__builtin_memcpy' offset [17, 2147483647] is out of the bounds [0, 16] of object 'buf' with type 'u8[16]' {aka 'unsigned char[16]'} [-Werror=array-bounds=] 212 | src = dst = memcpy(buf + sizeof(buf) - bytes, arch/arm/crypto/aes-neonbs-glue.c: In function 'ctr_encrypt': arch/arm/crypto/aes-neonbs-glue.c:218:17: error: 'aesbs_ctr_encrypt' reading 1 byte from a region of size 0 [-Werror=stringop-overread] 218 | aesbs_ctr_encrypt(dst, src, ctx->rk, ctx->rounds, bytes, walk.iv); | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ arch/arm/crypto/aes-neonbs-glue.c:218:17: note: referencing argument 2 of type 'const u8[0]' {aka 'const unsigned char[]'} arch/arm/crypto/aes-neonbs-glue.c:218:17: note: referencing argument 3 of type 'const u8[0]' {aka 'const unsigned char[]'} arch/arm/crypto/aes-neonbs-glue.c:218:17: note: referencing argument 6 of type 'u8[0]' {aka 'unsigned char[]'} arch/arm/crypto/aes-neonbs-glue.c:36:17: note: in a call to function 'aesbs_ctr_encrypt' 36 | asmlinkage void aesbs_ctr_encrypt(u8 out[], u8 const in[], u8 const rk[], This could happen in theory if walk.nbytes is larger than INT_MAX and gets converted to a negative local variable. Keep the type unsigned like the orignal nbytes to be sure there is no integer overflow. Fixes: c8bf850e991a ("crypto: arm/aes-neonbs-ctr - deal with non-multiples of AES block size") Signed-off-by: Arnd Bergmann <arnd@arndb.de> Acked-by: Ard Biesheuvel <ardb@kernel.org> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2025-06-18padata: Remove comment for reorder_workHerbert Xu
Remove comment for reorder_work which no longer exists. Reported-by: Stephen Rothwell <sfr@canb.auug.org.au> Fixes: 71203f68c774 ("padata: Fix pd UAF once and for all") Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2025-06-13Documentation: qat: update sysfs-driver-qat for GEN6 devicesSuman Kumar Chakraborty
Reorganize and expand documentation for service configurations. This reworks the `cfg_services` section by removing explicit service combinations (e.g., asym;sym, sym;asym) and clarifying that multiple services can be configured in any order. Update the documentation to reflect that the attribute previously limited to qat_4xxx devices is also applicable to qat_6xxx devices. Signed-off-by: Suman Kumar Chakraborty <suman.kumar.chakraborty@intel.com> Reviewed-by: Giovanni Cabiddu <giovanni.cabiddu@intel.com> Reviewed-by: Fiona Trahe <fiona.trahe@intel.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2025-06-13crypto: qat - add support for decompression service to GEN6 devicesSuman Kumar Chakraborty
Add support to configure decompression as a separate service for QAT GEN6 devices. A new arbiter configuration has been added to map the hardware decompression threads to all ring pairs. The decompression service is enabled via sysfs by writing "decomp" to "/sys/bus/pci/devices/<BDF>/qat/cfg_services". The decompression service is not supported on QAT GEN2 and GEN4 devices, and attempting it results in an invalid write error. The existing compression service for QAT GEN2 and GEN4 devices remains unchanged and supports both compression and decompression operations on the same ring pair. Co-developed-by: Karthikeyan Gopal <karthikeyan.gopal@intel.com> Signed-off-by: Karthikeyan Gopal <karthikeyan.gopal@intel.com> Signed-off-by: Suman Kumar Chakraborty <suman.kumar.chakraborty@intel.com> Reviewed-by: Giovanni Cabiddu <giovanni.cabiddu@intel.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2025-06-13padata: use cpumask_nth()Yury Norov
padata_do_parallel() and padata_index_to_cpu() duplicate cpumask_nth(). Fix both and use the generic helper. Signed-off-by: Yury Norov <yury.norov@gmail.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2025-06-13crypto: caam - Fix opencoded cpumask_next_wrap() in caam_drv_ctx_init()Yury Norov [NVIDIA]
The dedicated cpumask_next_wrap() is more verbose and better optimized comparing to cpumask_next() followed by cpumask_first(). Signed-off-by: Yury Norov [NVIDIA] <yury.norov@gmail.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2025-06-13crypto: pcrypt - Optimize pcrypt_aead_init_tfm()Yury Norov [NVIDIA]
The function opencodes cpumask_nth(). The dedicated helper is faster than an open for-loop. Signed-off-by: Yury Norov [NVIDIA] <yury.norov@gmail.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2025-06-13crypto: qat - fix state restore for banks with exceptionsSvyatoslav Pankratov
Change the logic in the restore function to properly handle bank exceptions. The check for exceptions in the saved state should be performed before conducting any other ringstat register checks. If a bank was saved with an exception, the ringstat will have the appropriate rp_halt/rp_exception bits set, causing the driver to exit the restore process with an error. Instead, the restore routine should first check the ringexpstat register, and if any exception was raised, it should stop further checks and return without any error. In other words, if a ring pair is in an exception state at the source, it should be restored the same way at the destination but without raising an error. Even though this approach might lead to losing the exception state during migration, the driver will log the exception from the saved state during the restore process. Signed-off-by: Svyatoslav Pankratov <svyatoslav.pankratov@intel.com> Fixes: bbfdde7d195f ("crypto: qat - add bank save and restore flows") Signed-off-by: Giovanni Cabiddu <giovanni.cabiddu@intel.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2025-06-13crypto: qat - allow enabling VFs in the absence of IOMMUAhsan Atta
The commit ca88a2bdd4dd ("crypto: qat - allow disabling SR-IOV VFs") introduced an unnecessary change that prevented enabling SR-IOV when IOMMU is disabled. In certain scenarios, it is desirable to enable SR-IOV even in the absence of IOMMU. Thus, restoring the previous functionality to allow VFs to be enumerated in the absence of IOMMU. Fixes: ca88a2bdd4dd ("crypto: qat - allow disabling SR-IOV VFs") Signed-off-by: Ahsan Atta <ahsan.atta@intel.com> Reviewed-by: Giovanni Cabiddu <giovanni.cabiddu@intel.com> Reviewed-by: Michal Witwicki <michal.witwicki@intel.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2025-06-13crypto: ccp - Fix dereferencing uninitialized error pointerAshish Kalra
Fix below smatch warnings: drivers/crypto/ccp/sev-dev.c:1312 __sev_platform_init_locked() error: we previously assumed 'error' could be null Fixes: 9770b428b1a2 ("crypto: ccp - Move dev_info/err messages for SEV/SNP init and shutdown") Reported-by: Dan Carpenter <dan.carpenter@linaro.org> Closes: https://lore.kernel.org/r/202505071746.eWOx5QgC-lkp@intel.com/ Signed-off-by: Ashish Kalra <ashish.kalra@amd.com> Reviewed-by: Tom Lendacky <thomas.lendacky@amd.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2025-06-13crypto: octeontx2 - get engine group number for asymmetric engineAmit Singh Tomar
Cryptographic Accelerator Unit (CPT) support different engine groups, one for asymmetric algorithms (only AE engines in this group), one for the most common symmetric algorithms (all SE and all IE engines in this group), and one for other symmetric algorithms (only SE engines in this group). For symmetric engine (SE), we obtain the group number using "MBOX_MSG_GET_ENG_GRP_NUM" mailbox. Let's follow a similar approach to determine the group number for asymmetric engine (AE). Signed-off-by: Amit Singh Tomar <amitsinght@marvell.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2025-06-13crypto: octeontx2 - Rework how engine group number is obtainedAmit Singh Tomar
By default, otx2_cpt_get_kcrypto_eng_grp_num() returns the engine group number of SE engine type. Add an engine type parameter to support retrieving the engine group number for different engine types. Since otx2_cpt_get_kcrypto_eng_grp_num() always returns the kernel crypto engine group number, rename it to otx2_cpt_get_eng_grp_num(). Signed-off-by: Amit Singh Tomar <amitsinght@marvell.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2025-06-13padata: Fix pd UAF once and for allHerbert Xu
There is a race condition/UAF in padata_reorder that goes back to the initial commit. A reference count is taken at the start of the process in padata_do_parallel, and released at the end in padata_serial_worker. This reference count is (and only is) required for padata_replace to function correctly. If padata_replace is never called then there is no issue. In the function padata_reorder which serves as the core of padata, as soon as padata is added to queue->serial.list, and the associated spin lock released, that padata may be processed and the reference count on pd would go away. Fix this by getting the next padata before the squeue->serial lock is released. In order to make this possible, simplify padata_reorder by only calling it once the next padata arrives. Fixes: 16295bec6398 ("padata: Generic parallelization/serialization interface") Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2025-06-13crypto: s390/sha3 - Use cpu byte-order when exportingHerbert Xu
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 Xu
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-06-13crypto: marvell/cesa - Fix engine load inaccuracyHerbert Xu
If an error occurs during queueing the engine load will never be decremented. Fix this by moving the engine load adjustment into the cleanup function. Fixes: bf8f91e71192 ("crypto: marvell - Add load balancing between engines") Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2025-06-13crypto: octeontx2 - Fix address alignment on CN10KB and CN10KA-B0Bharat Bhushan
octeontx2 crypto driver allocates memory using kmalloc/kzalloc, and uses this memory for dma (does dma_map_single()). It assumes that kmalloc/kzalloc will return 128-byte aligned address. But kmalloc/kzalloc returns 8-byte aligned address after below changes: "9382bc44b5f5 arm64: allow kmalloc() caches aligned to the smaller cache_line_size() Memory allocated are used for following purpose: - Input data or scatter list address - 8-Byte alignment - Output data or gather list address - 8-Byte alignment - Completion address - 32-Byte alignment. This patch ensures all addresses are aligned as mentioned above. Signed-off-by: Bharat Bhushan <bbhushan2@marvell.com> Cc: <stable@vger.kernel.org> # v6.8+ Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2025-06-13crypto: octeontx2 - Fix address alignment on CN10K A0/A1 and OcteonTX2Bharat Bhushan
octeontx2 crypto driver allocates memory using kmalloc/kzalloc, and uses this memory for dma (does dma_map_single()). It assumes that kmalloc/kzalloc will return 128-byte aligned address. But kmalloc/kzalloc returns 8-byte aligned address after below changes: "9382bc44b5f5 arm64: allow kmalloc() caches aligned to the smaller cache_line_size() Memory allocated are used for following purpose: - Input data or scatter list address - 8-Byte alignment - Output data or gather list address - 8-Byte alignment - Completion address - 32-Byte alignment. This patch ensures all addresses are aligned as mentioned above. Signed-off-by: Bharat Bhushan <bbhushan2@marvell.com> Cc: <stable@vger.kernel.org> # v6.5+ Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2025-06-13crypto: octeontx2 - Fix address alignment issue on ucode loadingBharat Bhushan
octeontx2 crypto driver allocates memory using kmalloc/kzalloc, and uses this memory for dma (does dma_map_single()). It assumes that kmalloc/kzalloc will return 128-byte aligned address. But kmalloc/kzalloc returns 8-byte aligned address after below changes: "9382bc44b5f5 arm64: allow kmalloc() caches aligned to the smaller cache_line_size()" Completion address should be 32-Byte alignment when loading microcode. Signed-off-by: Bharat Bhushan <bbhushan2@marvell.com> Cc: <stable@vger.kernel.org> # v6.5+ Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2025-06-13crypto: octeontx2 - add timeout for load_fvc completion pollBharat Bhushan
Adds timeout to exit from possible infinite loop, which polls on CPT instruction(load_fvc) completion. Signed-off-by: Srujana Challa <schalla@marvell.com> Signed-off-by: Bharat Bhushan <bbhushan2@marvell.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2025-06-13crypto: marvell/cesa - Remove unnecessary state setting on finalHerbert Xu
There is no point in setting the hash state after finalisation since the hash state must never be used again. Remove that code. Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
generated by cgit (git 2.34.1) at 2025-09-08 14:31:41 +0000