[PATCH v3] crypto: api - check for ERR pointers in crypto_destroy_tfm()

Given that crypto_alloc_tfm() may return ERR pointers, and to avoid crashes on obscure error paths where such pointers are presented to crypto_destroy_tfm() (such as [0]), add an ERR_PTR check there before dereferencing the second argument as a struct crypto_tfm pointer. [0] https://lore.kernel.o

Re: CAAM RNG trouble

On Tue, 2021-03-02 at 19:33 +0200, Horia Geantă wrote: > On 12/14/2020 9:00 PM, Lucas Stach wrote: > > Hi all, > > > > I've been looking into a CAAM RNG issue for a while, where I could need > > some input from people knowing the CAAM hardware better than I do. > > Basically the issue is that on s

Beginner's questions

Hello everyone! I have a very great interest in improving the linux kernel, with special regards to cryptography. However, due to my lack of knowledge, I do not know exactly how can I do so. Thus, I have a few questions regarding this: How exactly do I start contributing to the linux-crypto subsy

Re: CAAM RNG trouble

On 12/14/2020 9:00 PM, Lucas Stach wrote: > Hi all, > > I've been looking into a CAAM RNG issue for a while, where I could need > some input from people knowing the CAAM hardware better than I do. > Basically the issue is that on some i.MX6 units the RNG functionality > sometimes fails with this e

Re: [PATCH v2] crypto: api - check for ERR pointers in crypto_destroy_tfm()

On Tue, Mar 02, 2021 at 08:55:30AM +0100, Ard Biesheuvel wrote: > diff --git a/include/crypto/hash.h b/include/crypto/hash.h > index 13f8a6a54ca8..f065dbe2205c 100644 > --- a/include/crypto/hash.h > +++ b/include/crypto/hash.h > @@ -281,6 +281,8 @@ static inline struct crypto_tfm *crypto_ahash_tfm(

[PATCH] crypto: sun8i-ss: fix result memory leak on error path

This patch fixes a memory leak on an error path. Fixes: d9b45418a917 ("crypto: sun8i-ss - support hash algorithms") Reported-by: kernel test robot Reported-by: Dan Carpenter Signed-off-by: Corentin Labbe --- drivers/crypto/allwinner/sun8i-ss/sun8i-ss-hash.c | 2 +- 1 file changed, 1 insertion(

Re: [PATCH] crypto: sun8i-ss: Fix memory leak of object d when dma_iv fails to map

Le Tue, Mar 02, 2021 at 04:34:46PM +, Colin King a écrit : > From: Colin Ian King > > In the case where the dma_iv mapping fails, the return error path leaks > the memory allocated to object d. Fix this by adding a new error return > label and jumping to this to ensure d is free'd before the

[PATCH] crypto: sun8i-ss: Fix memory leak of object d when dma_iv fails to map

From: Colin Ian King In the case where the dma_iv mapping fails, the return error path leaks the memory allocated to object d. Fix this by adding a new error return label and jumping to this to ensure d is free'd before the return. Addresses-Coverity: ("Resource leak") Fixes: ac2614d721de ("cry

Re: [PATCH v2] crypto: sun8i-ce: use kfree_sensitive() instead of

On Tue, Mar 02, 2021 at 05:09:05PM +0800, Yang Li wrote: > Use kfree_sensitive() instead of using kfree() to make the intention > of the API more explicit. Why did you keep the memzeros? Thanks, -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.

[PATCH v2] crypto: sun8i-ce: use kfree_sensitive() instead of

Use kfree_sensitive() instead of using kfree() to make the intention of the API more explicit. fixed the following coccicheck: ./drivers/crypto/allwinner/sun8i-ce/sun8i-ce-prng.c:30:16-17: WARNING opportunity for kfree_sensitive/kvfree_sensitive (memset at line 29) ./drivers/crypto/allwinner/sun

[PATCH v2 8/9] crypto: arm64/aes-ce - stop using SIMD helper for skciphers

Calls into the skcipher API can only occur from contexts where the SIMD unit is available, so there is no need for the SIMD helper. Signed-off-by: Ard Biesheuvel --- arch/arm64/crypto/Kconfig| 2 - arch/arm64/crypto/aes-glue.c | 102 +++- 2 files changed, 13 insertions(+),

[PATCH v2 9/9] crypto: arm64/aes-neonbs - stop using SIMD helper for skciphers

Calls into the skcipher API can only occur from contexts where the SIMD unit is available, so there is no need for the SIMD helper. Signed-off-by: Ard Biesheuvel --- arch/arm64/crypto/Kconfig | 1 - arch/arm64/crypto/aes-neonbs-glue.c | 122 ++-- 2 files changed, 9 in

[PATCH v2 4/9] crypto: aead - disallow en/decrypt for non-task or non-softirq context

In order to ensure that kernel mode SIMD routines will not need a scalar fallback if they run with softirqs disabled, disallow any use of the AEAD encrypt and decrypt routines from outside of task or softirq context. Signed-off-by: Ard Biesheuvel --- crypto/aead.c | 10 ++ 1 file changed

[PATCH v2 7/9] crypto: arm64/aes-ccm - remove non-SIMD fallback path

AES/CCM on arm64 is implemented as a synchronous AEAD, and so it is guaranteed by the API that it is only invoked in task or softirq context. Since softirqs are now only handled when the SIMD is not being used in the task context that was interrupted to service the softirq, we no longer need a fall

[PATCH v2 6/9] crypto: arm64/gcm-aes-ce - remove non-SIMD fallback path

Now that kernel mode SIMD is guaranteed to be available when executing in task or softirq context, we no longer need scalar fallbacks to use when the NEON is unavailable. So get rid of them. Signed-off-by: Ard Biesheuvel --- arch/arm64/crypto/ghash-ce-glue.c | 209 +--- 1 file ch

[PATCH v2 1/9] arm64: assembler: remove conditional NEON yield macros

The users of the conditional NEON yield macros have all been switched to the simplified cond_yield macro, and so the NEON specific ones can be removed. Signed-off-by: Ard Biesheuvel --- arch/arm64/include/asm/assembler.h | 70 1 file changed, 70 deletions(-) diff --git a/ar

[PATCH v2 5/9] crypto: skcipher - disallow en/decrypt for non-task or non-softirq context

In order to ensure that kernel mode SIMD routines will not need a scalar fallback if they run with softirqs disabled, disallow any use of the skcipher encrypt and decrypt routines from outside of task or softirq context. Signed-off-by: Ard Biesheuvel --- crypto/skcipher.c | 10 ++ 1 file

[PATCH v2 2/9] arm64: assembler: introduce wxN aliases for wN registers

The AArch64 asm syntax has this slightly tedious property that the names used in mnemonics to refer to registers depend on whether the opcode in question targets the entire 64-bits (xN), or only the least significant 8, 16 or 32 bits (wN). When writing parameterized code such as macros, this can be

[PATCH v2 3/9] arm64: fpsimd: run kernel mode NEON with softirqs disabled

Kernel mode NEON can be used in task or softirq context, but only in a non-nesting manner, i.e., softirq context is only permitted if the interrupt was not taken at a point where the kernel was using the NEON in task context. This means all users of kernel mode NEON have to be aware of this limita

[PATCH v2 0/9] running kernel mode SIMD with softirqs disabled

[ TL;DR for the non-ARM folks on CC: disabling softirq processing when using SIMD in kernel mode could reduce complexity and improve performance, but we need to decide whether we can do this, and how much softirq processing latency we can tolerate. If we can find a satisfactory solution for t

[PATCH v9 9/9] certs: Add support for using elliptic curve keys for signing modules

在 2021/3/1 21:11, Mimi Zohar 写道: On Sat, 2021-02-27 at 11:35 +0800, yumeng wrote: 在 2021/2/26 0:08, Stefan Berger 写道: From: Stefan Berger diff --git a/certs/Makefile b/certs/Makefile index 3fe6b73786fa..c487d7021c54 100644 --- a/certs/Makefile +++ b/certs/Makefile @@ -69,6 +69,18 @@ els

[PATCH v2] crypto: api - check for ERR pointers in crypto_destroy_tfm()

Given that crypto_alloc_tfm() may return ERR pointers, and to avoid crashes on obscure error paths where such pointers are presented to crypto_destroy_tfm() (such as [0]), add an ERR_PTR check there before dereferencing the second argument as a struct crypto_tfm pointer. [0] https://lore.kernel.o