- 18 Aug, 2023 23 commits
-
-
Herbert Xu authored
The callbacks for prepare and unprepare request in crypto_engine is superfluous. They can be done directly from do_one_request. Move the code into do_one_request and remove the unused callbacks. Signed-off-by:Herbert Xu <herbert@gondor.apana.org.au>
-
Herbert Xu authored
The callbacks for prepare and unprepare request in crypto_engine is superfluous. They can be done directly from do_one_request. Move the code into do_one_request and remove the unused callbacks. Signed-off-by: -
Herbert Xu authored
The callbacks for prepare and unprepare request in crypto_engine is superfluous. They can be done directly from do_one_request. Move the code into do_one_request and remove the unused callbacks. Signed-off-by: -
Herbert Xu authored
The callbacks for prepare and unprepare request in crypto_engine is superfluous. They can be done directly from do_one_request. Move the code into do_one_request and remove the unused callbacks. Signed-off-by: -
Herbert Xu authored
The callbacks for prepare and unprepare request in crypto_engine is superfluous. They can be done directly from do_one_request. Move the code into do_one_request and remove the unused callbacks. Signed-off-by: -
Herbert Xu authored
The callbacks for prepare and unprepare request in crypto_engine is superfluous. They can be done directly from do_one_request. Move the code into do_one_request and remove the unused callbacks. Signed-off-by: -
Herbert Xu authored
The callbacks for prepare and unprepare request in crypto_engine is superfluous. They can be done directly from do_one_request. Move the code into do_one_request and remove the unused callbacks. Signed-off-by: -
Herbert Xu authored
The callbacks for prepare and unprepare request in crypto_engine is superfluous. They can be done directly from do_one_request. Move the code into do_one_request and remove the unused callbacks. Signed-off-by: -
Herbert Xu authored
The callbacks for prepare and unprepare request in crypto_engine is superfluous. They can be done directly from do_one_request. Move the code into do_one_request and remove the unused callbacks. Signed-off-by: -
Herbert Xu authored
The callbacks for prepare and unprepare request in crypto_engine is superfluous. They can be done directly from do_one_request. Move the code into do_one_request and remove the unused callbacks. Signed-off-by: -
Herbert Xu authored
The callbacks for prepare and unprepare request in crypto_engine is superfluous. They can be done directly from do_one_request. Move the code into do_one_request and remove the unused callbacks. Signed-off-by: -
Konrad Dybcio authored
Some newer SoCs (like SM8450) do not require a clock vote for the PRNG to function. Make it entirely optional and rely on the bindings checker to ensure platforms that need it, consume one. Signed-off-by:
Konrad Dybcio <konrad.dybcio@linaro.org> Reviewed-by:
Bjorn Andersson <andersson@kernel.org> Signed-off-by:
-
Konrad Dybcio authored
SM8450's PRNG does not require a core clock reference. Add a new compatible with a qcom,prng-ee fallback and handle that. Signed-off-by:
Conor Dooley <conor.dooley@microchip.com> Signed-off-by:
-
Arnd Bergmann authored
Some configurations with gcc-12 or gcc-13 produce a warning for the source and destination of a memcpy() in atmel_sha_hmac_compute_ipad_hash() potentially overlapping: In file included from include/linux/string.h:254, from drivers/crypto/atmel-sha.c:15: drivers/crypto/atmel-sha.c: In function 'atmel_sha_hmac_compute_ipad_hash': include/linux/fortify-string.h:57:33: error: '__builtin_memcpy' accessing 129 or more bytes at offsets 408 and 280 overlaps 1 or more bytes at offset 408 [-Werror=restrict] 57 | #define __underlying_memcpy __builtin_memcpy | ^ include/linux/fortify-string.h:648:9: note: in expansion of macro '__underlying_memcpy' 648 | __underlying_##op(p, q, __fortify_size); \ | ^~~~~~~~~~~~~ include/linux/fortify-string.h:693:26: note: in expansion of macro '__fortify_memcpy_chk' 693 | #define memcpy(p, q, s) __fortify_memcpy_chk(p, q, s, \ | ^~~~~~~~~~~~~~~~~~~~ drivers/crypto/atmel-sha.c:1773:9: note: in expansion of macro 'memcpy' 1773 | memcpy(hmac->opad, hmac->ipad, bs); | ^~~~~~ The same thing happens in two more drivers that have the same logic: drivers/crypto/chelsio/chcr_algo.c: In function 'chcr_ahash_setkey': include/linux/fortify-string.h:57:33: error: '__builtin_memcpy' accessing 129 or more bytes at offsets 260 and 132 overlaps 1 or more bytes at offset 260 [-Werror=restrict] drivers/crypto/bcm/cipher.c: In function 'ahash_hmac_setkey': include/linux/fortify-string.h:57:33: error: '__builtin_memcpy' accessing between 129 and 4294967295 bytes at offsets 840 and 712 overlaps between 1 and 4294967167 bytes at offset 840 [-Werror=restrict] I don't think it can actually happen because the size is strictly bounded to the available block sizes, at most 128 bytes, though inlining decisions could lead gcc to not see that. Use the unsafe_memcpy() helper instead of memcpy(), with the only difference being that this skips the hardening checks that produce the warning. Suggested-by:Arnd Bergmann <arnd@arndb.de> Signed-off-by:
-
Florian Fainelli authored
Chips such as BCM7278 support system wide suspend/resume which will cause the HWRNG block to lose its state and reset to its power on reset register values. We need to cleanup and re-initialize the HWRNG for it to be functional coming out of a system suspend cycle. Fixes: c3577f61 ("hwrng: iproc-rng200 - Add support for BCM7278") Signed-off-by:
Florian Fainelli <florian.fainelli@broadcom.com> Signed-off-by:
-
GUO Zihua authored
Remove duplicated include of linux/random.h. Resolves checkincludes message. And adjust includes in alphabetical order. Signed-off-by:
GUO Zihua <guozihua@huawei.com> Signed-off-by:
-
Krzysztof Kozlowski authored
'type' is an enum, thus cast of pointer on 64-bit compile test with W=1 causes: exynos-rng.c:280:14: error: cast to smaller integer type 'enum exynos_prng_type' from 'const void *' [-Werror,-Wvoid-pointer-to-enum-cast] Signed-off-by:
Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Signed-off-by:
-
Yue Haibing authored
Commit d8cba25d ("crypto: qat - Intel(R) QAT driver framework") declared but never implemented these functions. Signed-off-by:
Yue Haibing <yuehaibing@huawei.com> Acked-by:
Giovanni Cabiddu <giovanni.cabiddu@intel.com> Signed-off-by:
-
Yue Haibing authored
Commit 06f751b6 ("crypto: allwinner - Add sun8i-ce Crypto Engine") declared but never implemented sun8i_ce_enqueue(). Commit 56f6d5ae ("crypto: sun8i-ce - support hash algorithms") declared but never implemented sun8i_ce_hash(). Commit f08fcced ("crypto: allwinner - Add sun8i-ss cryptographic offloader") declared but never implemented sun8i_ss_enqueue(). Signed-off-by:
-
Horia Geantă authored
There are cases when the interrupt status register (JRINTR) is non-zero, even though: 1. An interrupt was generated, but it was masked OR 2. There was no interrupt generated at all for the corresponding job ring. 1. The case when interrupt is masked (JRCFGR_LS[IMSK]=1b'1) while other events have happened and are being accounted for, e.g. -JRINTR[HALT]=2b'10 - input job ring underwent a flush of all on-going jobs and processing of still-existing jobs (sitting in the ring) has been halted -JRINTR[HALT]=2b'01 - input job ring is currently undergoing a flush -JRINTR[ENTER_FAIL]=1b'1 - SecMon / SNVS transitioned to FAIL MODE It doesn't matter whether these events would assert the interrupt signal or not, interrupt is anyhow masked. 2. The case when interrupt is not masked (JRCFGR_LS[IMSK]=1b'0), however the events accounted for in JRINTR do not generate interrupts, e.g.: -JRINTR[HALT]=2b'01 -JRINTR[ENTER_FAIL]=1b'1 and JRCFGR_MS[FAIL_MODE]=1b'0 Currently in these cases, when the JR interrupt handler is invoked (as a consequence of JR sharing the interrupt line with other devices - e.g. the two JRs on i.MX7ULP) it continues execution instead of returning IRQ_NONE. This could lead to situations like interrupt handler clearing JRINTR (and thus also the JRINTR[HALT] field) while corresponding job ring is suspended and then that job ring failing on resume path, due to expecting JRINTR[HALT]=b'10 and reading instead JRINTR[HALT]=b'00. Fix this by checking status of JRINTR[JRI] in the JR interrupt handler. If JRINTR[JRI]=1b'0, there was no interrupt generated for this JR and handler must return IRQ_NONE. Signed-off-by:
Horia Geantă <horia.geanta@nxp.com> Signed-off-by:
Meenakshi Aggarwal <meenakshi.aggarwal@nxp.com> Reviewed-by:
Gaurav Jain <gaurav.jain@nxp.com> Signed-off-by:
-
Iuliana Prodan authored
In caam_jr_enqueue, under heavy DDR load, smp_wmb() or dma_wmb() fail to make the input ring be updated before the CAAM starts reading it. So, CAAM will process, again, an old descriptor address and will put it in the output ring. This will make caam_jr_dequeue() to fail, since this old descriptor is not in the software ring. To fix this, use wmb() which works on the full system instead of inner/outer shareable domains. Signed-off-by:
Iuliana Prodan <iuliana.prodan@nxp.com> Signed-off-by:
-
Gaurav Jain authored
error: Unchecked return value (CHECKED_RETURN) check_return: Calling sg_miter_next without checking return value fix: added check if(!sg_miter_next) Fixes: 8a2a0dd3 ("crypto: caam - strip input zeros from RSA input buffer") Signed-off-by:
-
Arnd Bergmann authored
The newly added PM operations use the deprecated SIMPLE_DEV_PM_OPS() macro, causing a warning in some configurations: drivers/crypto/caam/ctrl.c:828:12: error: 'caam_ctrl_resume' defined but not used [-Werror=unused-function] 828 | static int caam_ctrl_resume(struct device *dev) | ^~~~~~~~~~~~~~~~ drivers/crypto/caam/ctrl.c:818:12: error: 'caam_ctrl_suspend' defined but not used [-Werror=unused-function] 818 | static int caam_ctrl_suspend(struct device *dev) | ^~~~~~~~~~~~~~~~~ drivers/crypto/caam/jr.c:732:12: error: 'caam_jr_resume' defined but not used [-Werror=unused-function] 732 | static int caam_jr_resume(struct device *dev) | ^~~~~~~~~~~~~~ drivers/crypto/caam/jr.c:687:12: error: 'caam_jr_suspend' defined but not used [-Werror=unused-function] 687 | static int caam_jr_suspend(struct device *dev) | ^~~~~~~~~~~~~~~ Use the normal DEFINE_SIMPLE_DEV_PM_OPS() variant now, and use pm_ptr() to completely eliminate the structure in configs without CONFIG_PM. Fixes: 322d7475 ("crypto: caam - add power management support") Signed-off-by:
-
- 11 Aug, 2023 12 commits
-
-
Joachim Vandersmissen authored
The RCT cutoff values are correct, but they don't exactly match the ones one would expect when computing them using the formula in SP800-90B. This discrepancy is due to the fact that the Jitter Entropy RCT starts at 1. To avoid any confusion by future reviewers, add some comments and explicitly subtract 1 from the "correct" cutoff values in the definitions. Signed-off-by:
Joachim Vandersmissen <git@jvdsn.com> Reviewed-by:
Stephan Mueller <smueller@chronox.de> Signed-off-by:
-
Mark O'Donovan authored
During NVMeTCP Authentication a controller can trigger a kernel oops by specifying the 8192 bit Diffie Hellman group and passing a correctly sized, but zeroed Diffie Hellamn value. mpi_cmp_ui() was detecting this if the second parameter was 0, but 1 is passed from dh_is_pubkey_valid(). This causes the null pointer u->d to be dereferenced towards the end of mpi_cmp_ui() Signed-off-by:
Mark O'Donovan <shiftee@posteo.net> Signed-off-by:
-
Herbert Xu authored
As lib/mpi is mostly used by crypto code, move it under lib/crypto so that patches touching it get directed to the right mailing list. Signed-off-by:
Mimi Zohar <zohar@linux.ibm.com> Signed-off-by:
-
Herbert Xu authored
The function crypto_drop_spawn expects to be called in process context. However, when an instance is unregistered while it still has active users, the last user may cause the instance to be freed in atomic context. Fix this by delaying the freeing to a work queue. Fixes: 6bfd4809 ("[CRYPTO] api: Added spawns") Reported-by:
Florent Revest <revest@chromium.org> Reported-by: syzbot+d769eed29cc42d75e2a3@syzkaller.appspotmail.com Reported-by: syzbot+610ec0671f51e838436e@syzkaller.appspotmail.com Signed-off-by:
-
Ruan Jinjie authored
Since commit ce753ad1 ("platform: finally disallow IRQ0 in platform_get_irq() and its ilk"), there is no possible for platform_get_irq() to return 0. Use the return value from platform_get_irq(). Signed-off-by:
Ruan Jinjie <ruanjinjie@huawei.com> Signed-off-by:
-
Yang Yingliang authored
Use kfree_sensitive() instead of memset() and kfree(). Signed-off-by:
Yang Yingliang <yangyingliang@huawei.com> Acked-by:
-
Frederick Lawler authored
Calls to lookup_user_key() require a corresponding key_put() to decrement the usage counter. Once it reaches zero, we schedule key GC. Therefore decrement struct key.usage in alg_set_by_key_serial(). Fixes: 7984ceb1 ("crypto: af_alg - Support symmetric encryption via keyring keys") Cc: <stable@vger.kernel.org> Signed-off-by:
Frederick Lawler <fred@cloudflare.com> Signed-off-by:
-
Masahiro Yamada authored
Do it more simiply. This also fixes single target builds. [before] $ make ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu- arch/arm64/crypto/aes-glue-ce.i [snip] make[4]: *** No rule to make target 'arch/arm64/crypto/aes-glue-ce.i'. Stop. [after] $ make ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu- arch/arm64/crypto/aes-glue-ce.i [snip] CPP arch/arm64/crypto/aes-glue-ce.i Signed-off-by:Masahiro Yamada <masahiroy@kernel.org> Acked-by:
Will Deacon <will@kernel.org> Signed-off-by:
-
Uwe Kleine-König authored
The .remove() callback for a platform driver returns an int which makes many driver authors wrongly assume it's possible to do error handling by returning an error code. However the value returned is ignored (apart from emitting a warning) and this typically results in resource leaks. To improve here there is a quest to make the remove callback return void. In the first step of this quest all drivers are converted to .remove_new() which already returns void. Eventually after all drivers are converted, .remove_new() is renamed to .remove(). Trivially convert this driver from always returning zero in the remove callback to the void returning variant. Signed-off-by:
Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Signed-off-by:
-
Uwe Kleine-König authored
stm32_hash_remove() is only called after stm32_hash_probe() succeeded. In this case platform_set_drvdata() was called with a non-NULL data patameter. The check for hdev being non-NULL can be dropped because hdev is never NULL (or something bad like memory corruption happened and then the check doesn't help any more either). Signed-off-by:
-
Uwe Kleine-König authored
If pm_runtime_get() (disguised as pm_runtime_resume_and_get()) fails, this means the clk wasn't prepared and enabled. Returning early in this case however is wrong as then the following resource frees are skipped and this is never catched up. So do all the cleanups but clk_disable_unprepare(). Also don't emit a warning, as stm32_hash_runtime_resume() already emitted one. Note that the return value of stm32_hash_remove() is mostly ignored by the device core. The only effect of returning zero instead of an error value is to suppress another warning in platform_remove(). So return 0 even if pm_runtime_resume_and_get() failed. Fixes: 8b4d566d ("crypto: stm32/hash - Add power management support") Signed-off-by:
-
Yang Yingliang authored
kzalloc() returns NULL pointer not PTR_ERR() when it fails, so replace the IS_ERR() check with NULL pointer check. Fixes: e22471c2 ("crypto: starfive - Add AES skcipher and aead support") Signed-off-by:
-
- 05 Aug, 2023 1 commit
-
-
Rob Herring authored
Commit 0788257a ("hwrng: Explicitly include correct DT includes") removed an implicit include of io.h. On most architectures, there's still an implicit include of it, but not on s390. Enabling COMPILE_TEST in commit 1ce1cd82 ("hwrng: Enable COMPILE_TEST for more drivers") exposed this. Fixes: 0788257a ("hwrng: Explicitly include correct DT includes") Reported-by:
kernel test robot <lkp@intel.com> Closes: https://lore.kernel.org/oe-kbuild-all/202308042049.8R2tNRoo-lkp@intel.com/Signed-off-by:
Rob Herring <robh@kernel.org> Signed-off-by:
-
- 04 Aug, 2023 4 commits
-
-
Rob Herring authored
There's quite a few hwrng drivers which are easily enabled for COMPILE_TEST, so let's enable them. The dependency on HW_RANDOM is redundant, so drop that while we're here. Signed-off-by:
-
Rob Herring authored
The DT of_device.h and of_platform.h date back to the separate of_platform_bus_type before it was merged into the regular platform bus. As part of that merge prepping Arm DT support 13 years ago, they "temporarily" include each other. They also include platform_device.h and of.h. As a result, there's a pretty much random mix of those include files used throughout the tree. In order to detangle these headers and replace the implicit includes with struct declarations, users need to explicitly include the correct includes. Signed-off-by:
-
David Howells authored
Fix af_alg_alloc_areq() to initialise areq->first_rsgl.sgl.sgt.sgl to point to the scatterlist array in areq->first_rsgl.sgl.sgl. Without this, the gcm-aes-s390 driver will oops when it tries to do gcm_walk_start() on req->dst because req->dst is set to the value of areq->first_rsgl.sgl.sgl by _aead_recvmsg() calling aead_request_set_crypt(). The problem comes if an empty ciphertext is passed: the loop in af_alg_get_rsgl() just passes straight out and doesn't set areq->first_rsgl up. This isn't a problem on x86_64 using gcmaes_crypt_by_sg() because, as far as I can tell, that ignores req->dst and only uses req->src[*]. [*] Is this a bug in aesni-intel_glue.c? The s390x oops looks something like: Unable to handle kernel pointer dereference in virtual kernel address space Failing address: 0000000a00000000 TEID: 0000000a00000803 Fault in home space mode while using kernel ASCE. AS:00000000a43a0007 R3:0000000000000024 Oops: 003b ilc:2 [#1] SMP ... Call Trace: [<000003ff7fc3d47e>] gcm_walk_start+0x16/0x28 [aes_s390] [<00000000a2a342f2>] crypto_aead_decrypt+0x9a/0xb8 [<00000000a2a60888>] aead_recvmsg+0x478/0x698 [<00000000a2e519a0>] sock_recvmsg+0x70/0xb0 [<00000000a2e51a56>] sock_read_iter+0x76/0xa0 [<00000000a273e066>] vfs_read+0x26e/0x2a8 [<00000000a273e8c4>] ksys_read+0xbc/0x100 [<00000000a311d808>] __do_syscall+0x1d0/0x1f8 [<00000000a312ff30>] system_call+0x70/0x98 Last Breaking-Event-Address: [<000003ff7fc3e6b4>] gcm_aes_crypt+0x104/0xa68 [aes_s390] Fixes: c1abe6f5 ("crypto: af_alg: Use extract_iter_to_sg() to create scatterlists") Reported-by:
Ondrej Mosnáček <omosnacek@gmail.com> Link: https://lore.kernel.org/r/CAAUqJDuRkHE8fPgZJGaKjUjd3QfGwzfumuJBmStPqBhubxyk_A@mail.gmail.com/Signed-off-by:
David Howells <dhowells@redhat.com> cc: Herbert Xu <herbert@gondor.apana.org.au> cc: Sven Schnelle <svens@linux.ibm.com> cc: Harald Freudenberger <freude@linux.vnet.ibm.com> cc: "David S. Miller" <davem@davemloft.net> cc: Paolo Abeni <pabeni@redhat.com> cc: linux-crypto@vger.kernel.org cc: linux-s390@vger.kernel.org cc: regressions@lists.linux.dev Tested-by:
Sven Schnelle <svens@linux.ibm.com> Tested-by:
-
Wang Ming authored
It is possible that dma_request_chan will return EPROBE_DEFER, which means that dd->dev is not ready yet. In this case, dev_err(dd->dev), there will be no output. This patch fixes the bug. Signed-off-by:
Wang Ming <machel@vivo.com> Reviewed-by:
Ryan Wanner <Ryan.Wanner@microchip.com> Signed-off-by:
-
