[PATCH] crypto: AF_ALG - limit mask and type

Hi Herbert, you see the reported problem by simply using sa.salg_mask = 0x; Note, I am not fully sure about whether CRYPTO_AF_ALG_ALLOWED_MASK and CRYPTO_AF_ALG_ALLOWED_TYPE have the correct value. But I think that all that user space should reach is potentially the ASYNC flag and the

[PATCH] crypto: gf128mul - remove incorrect comment

From: Eric Biggers The comment in gf128mul_x8_ble() was copy-and-pasted from gf128mul.h and makes no sense in the new context. Remove it. Cc: Harsh Jain Signed-off-by: Eric Biggers --- crypto/gf128mul.c | 2 -- 1 file changed, 2

[PATCH] crypto: chacha20poly1305 - validate the digest size

From: Eric Biggers If the rfc7539 template was instantiated with a hash algorithm with digest size larger than 16 bytes (POLY1305_DIGEST_SIZE), then the digest overran the 'tag' buffer in 'struct chachapoly_req_ctx', corrupting the subsequent memory, including 'cryptlen'.

Re: general protection fault in blkcipher_walk_done

On Mon, Nov 27, 2017 at 10:56:47AM -0800, syzbot wrote: > syzbot will keep track of this bug report. > Once a fix for this bug is committed, please reply to this email with: > #syz fix: exact-commit-title > If you want to test a patch for this bug, please reply with: > #syz test:

Re: general protection fault in crypto_chacha20_crypt

On Wed, Nov 29, 2017 at 01:24:38AM -0800, Eric Biggers wrote: > > The bug is that the skcipher_walk API doesn't set the IV for zero-length > inputs, > while some algorithms (e.g. ChaCha20) access the IV even if the input is > zero-length. So it was dereferencing a pointer which came from

Re: KASAN: use-after-free Write in aead_recvmsg

On Mon, Dec 04, 2017 at 07:57:01AM -0800, syzbot wrote: > syzbot will keep track of this bug report. > Once a fix for this bug is committed, please reply to this email with: > #syz fix: exact-commit-title > If you want to test a patch for this bug, please reply with: > #syz test:

Re: general protection fault in strcmp

On Thu, Nov 30, 2017 at 12:44:01PM -0800, syzbot wrote: > syzbot will keep track of this bug report. > Once a fix for this bug is committed, please reply to this email with: > #syz fix: exact-commit-title > To mark this as a duplicate of another syzbot report, please reply with: > #syz dup:

Re: [PATCH v3 3/3] ARM: dts: exynos: Add nodes for True Random Number Generator

On Mon, Dec 04, 2017 at 01:53:51PM +0100, Łukasz Stelmach wrote: > Add nodes for the True Random Number Generator found in Samsung Exynos > 5250+ SoCs. > > Signed-off-by: Łukasz Stelmach > --- > arch/arm/boot/dts/exynos5.dtsi| 5 + >

Re: [PATCH] fscrypt: add support for ChaCha20 contents encryption

> On 08.12.2017, at 03:51, Jason A. Donenfeld wrote: > > Hi Eric, > > Nice to see more use of ChaCha20. However... > > Can we skip over the "sort of worse than XTS, but not having _real_ > authentication sucks anyway in either case, so whatever" and move > directly to, "linux

Re: [PATCH v2 4/4] crypto: exynos - Introduce mutex to prevent concurrent access to hardware

On Mon, Dec 11, 2017 at 3:06 PM, Łukasz Stelmach wrote: > Cc: Marek Szyprowski , Bartlomiej Zolnierkiewicz > > > Hardware operations like reading random numbers and setting a seed need > to be conducted in a single

Re: [PATCH v2 3/4] crypto: exynos - Reseed PRNG after generating 2^16 random bytes

On Mon, Dec 11, 2017 at 3:06 PM, Łukasz Stelmach wrote: > Cc: Marek Szyprowski , Bartlomiej Zolnierkiewicz > Same as in 1/4 and 2/4. > > Reseed PRNG after reading 65 kB of randomness. Although this may reduce >

Re: [PATCH v2 2/4] crypto: exynos - Improve performance of PRNG

On Mon, Dec 11, 2017 at 3:06 PM, Łukasz Stelmach wrote: > Cc: Marek Szyprowski , Bartlomiej Zolnierkiewicz > This should not appear here. > > Use memcpy_fromio() instead of custom exynos_rng_copy_random() function >

Re: [PATCH v2 1/4] crypto: exynos - Support Exynos5250+ SoCs

On Mon, Dec 11, 2017 at 3:06 PM, Łukasz Stelmach wrote: > Cc: Marek Szyprowski , Bartlomiej Zolnierkiewicz > > > Add support for PRNG in Exynos5250+ SoCs. > > Signed-off-by: Łukasz Stelmach >

Re: [PATCH] crypto: stm32: fix modular build

Hi Arnd, This issue was reported a few days ago, and Herbert applied the patch 2 minutes before you send the mail (see [https://www.mail-archive.com/linux-crypto@vger.kernel.org/msg29762.html]). Anyway, thank you for reporting this. Fabien On 11/12/17 12:47, Arnd Bergmann wrote: > Building

[PATCH v2 4/4] crypto: exynos - Introduce mutex to prevent concurrent access to hardware

Cc: Marek Szyprowski , Bartlomiej Zolnierkiewicz Hardware operations like reading random numbers and setting a seed need to be conducted in a single thread. Therefore a mutex is required to prevent multiple threads (processes) from accessing

[PATCH v2 3/4] crypto: exynos - Reseed PRNG after generating 2^16 random bytes

Cc: Marek Szyprowski , Bartlomiej Zolnierkiewicz Reseed PRNG after reading 65 kB of randomness. Although this may reduce performance, in most cases the loss is not noticeable. Reseeding of a PRNG does not increase entropy, but it helps

[PATCH v2 0/4] Assorted changes for Exynos PRNG driver

Hello, This is a series of patches for exynos-rng driver I've decided to create after adding support for Exynos5250+ chips. They do not strictly depend on each other, but I think it is better to send them as a single patch-set. The driver requires appropriate DT configuration introduced in

[PATCH v2 2/4] crypto: exynos - Improve performance of PRNG

Cc: Marek Szyprowski , Bartlomiej Zolnierkiewicz Use memcpy_fromio() instead of custom exynos_rng_copy_random() function to retrieve generated numbers from the registers of PRNG. Rearrange the loop around cpu_relax(). In a loop with while()

[PATCH v2 1/4] crypto: exynos - Support Exynos5250+ SoCs

Cc: Marek Szyprowski , Bartlomiej Zolnierkiewicz Add support for PRNG in Exynos5250+ SoCs. Signed-off-by: Łukasz Stelmach --- .../bindings/crypto/samsung,exynos-rng4.txt| 4 ++- drivers/crypto/exynos-rng.c

[PATCH] crypto: qat - reduce stack size with KASAN

Passing the register value by reference here leads a large amount of stack being used when CONFIG_KASAN is enabled: drivers/crypto/qat/qat_common/qat_hal.c: In function 'qat_hal_exec_micro_inst.constprop': drivers/crypto/qat/qat_common/qat_hal.c:963:1: error: the frame size of 1792 bytes is

Re: [PATCH] crypto: AF_ALG - fix race accessing cipher request

On Fri, Dec 08, 2017 at 11:50:37AM +0100, Stephan Müller wrote: > Hi Herbert, > > This patch would go on top of 7d2c3f54e6f646887d019faa45f35d6fe9fe82ce > "crypto: af_alg - remove locking in async callback" found in Linus' tree > which is not yet in the cryptodev-2.6 tree. > > In addition, this

Re: [PATCH v2] crypto: Add myself as co-maintainer for s5p-sss.c

On Fri, Dec 01, 2017 at 05:51:02PM +0100, Kamil Konieczny wrote: > Add myself as co-maintainer for Samsung Security SubSystem driver. > I have added major functionality to the driver [hash acceleration], > I have access to documentation and to hardware for testing, I can > also dedicate some of my

[PATCH] crypto: stm32: fix modular build

Building the stm32 crypto suport as a loadable module causes a build failure from a simple typo: drivers/crypto/stm32/stm32-cryp.c:1035:25: error: 'sti_dt_ids' undeclared here (not in a function); did you mean 'stm32_dt_ids'? This renames the reference to point to the correct symbol. Fixes:

Re: [PATCH] crypto: stm32: fix module device table name

On Thu, Nov 30, 2017 at 12:04:33PM +0100, Corentin Labbe wrote: > This patch fix the following build failure: > CC [M] drivers/crypto/stm32/stm32-cryp.o > In file included from drivers/crypto/stm32/stm32-cryp.c:11:0: > drivers/crypto/stm32/stm32-cryp.c:1049:25: error: 'sti_dt_ids' undeclared >

Re: [PATCH] chcr: remove unused variables net_device, pi, adap and cntrl

On Thu, Nov 30, 2017 at 02:11:44PM +, Colin King wrote: > From: Colin Ian King > > Variables adap, pi and cntrl are assigned but are never read, hence > they are redundant and can be removed. > > Cleans up various clang build warnings. > > Signed-off-by: Colin Ian

Re: [PATCH] chcr: ensure cntrl is initialized to fix bit-wise or'ing of garabage data

On Thu, Nov 30, 2017 at 02:23:54PM +, Colin King wrote: > From: Colin Ian King > > In the case where skb->ip_summed != CHECKSUM_PARTIAL then cntrl contains > garbage value and this is possibly being bit-wise or'd and stored into > cpl->ctrl1. Fix this by

Re: [PATCH] crypto: cryptd: make cryptd_max_cpu_qlen module parameter static

On Thu, Nov 30, 2017 at 11:26:14AM +, Colin King wrote: > From: Colin Ian King > > The cryptd_max_cpu_qlen module parameter is local to the source and does > not need to be in global scope, so make it static. > > Cleans up sparse warning: > crypto/cryptd.c:35:14:

Re: [PATCH] crypto: chelsio: make arrays sgl_ent_len and dsgl_ent_len static

On Thu, Nov 30, 2017 at 11:32:08AM +, Colin King wrote: > From: Colin Ian King > > The arrays sgl_ent_len and dsgl_ent_len are local to the source and do > not need to be in global scope, so make them static. Also re-format the > declarations to match the following

Re: [PATCH] crypto: mcryptd: protect the per-CPU queue with a lock

On Thu, Nov 30, 2017 at 01:39:27PM +0100, Sebastian Andrzej Siewior wrote: > mcryptd_enqueue_request() grabs the per-CPU queue struct and protects > access to it with disabled preemption. Then it schedules a worker on the > same CPU. The worker in mcryptd_queue_worker() guards access to the same >

Re: [PATCH v2] crypto: AF_ALG - wait for data at beginning of recvmsg

On Wed, Nov 29, 2017 at 12:02:23PM +0100, Stephan Müller wrote: > The wait for data is a non-atomic operation that can sleep and therefore > potentially release the socket lock. The release of the socket lock > allows another thread to modify the context data structure. The waiting > operation for

Re: [PATCH] crypto: skcipher - set walk.iv for zero-length inputs

On Wed, Nov 29, 2017 at 01:18:57AM -0800, Eric Biggers wrote: > From: Eric Biggers > > All the ChaCha20 algorithms as well as the ARM bit-sliced AES-XTS > algorithms call skcipher_walk_virt(), then access the IV (walk.iv) > before checking whether any bytes need to be

Re: [PATCH] crypto: caam/qi - use correct print specifier for size_t

On Tue, Nov 28, 2017 at 06:48:08PM +0200, Horia Geantă wrote: > Fix below warnings on ARMv7 by using %zu for printing size_t values: > > drivers/crypto/caam/caamalg_qi.c: In function aead_edesc_alloc: > drivers/crypto/caam/caamalg_qi.c:417:17: warning: format %lu expects argument > of type long

Re: [PATCH] crypto: arm/aes-neonbs Use PTR_ERR_OR_ZERO()

On Tue, Nov 28, 2017 at 12:06:06AM +0100, Vasyl Gomonovych wrote: > Fix ptr_ret.cocci warnings: > arch/arm/crypto/aes-neonbs-glue.c:184:1-3: WARNING: PTR_ERR_OR_ZERO can be > used > arch/arm/crypto/aes-neonbs-glue.c:261:1-3: WARNING: PTR_ERR_OR_ZERO can be > used > > Use PTR_ERR_OR_ZERO rather

Re: [PATCH] crypto: fix typo in KPP dependency of CRYPTO_ECDH

On Sun, Nov 26, 2017 at 12:16:46AM +0100, Hauke Mehrtens wrote: > This fixes a typo in the CRYPTO_KPP dependency of CRYPTO_ECDH. > > Fixes: 3c4b23901a0c ("crypto: ecdh - Add ECDH software support") > Cc: # v4.8+ > Signed-off-by: Hauke Mehrtens Patch

Re: [PATCH 6/6] crypto: tcrypt: add multibuf aead speed test

On Thu, Nov 30, 2017 at 10:09:32AM +, Gilad Ben-Yossef wrote: > The performance of some aead tfm providers is affected by > the amount of parallelism possible with the processing. > > Introduce an async aead concurrent multiple buffer > processing speed test to be able to test performance of

[PATCH v4 2/4] crypto: inside-secure - free requests even if their handling failed

This patch frees the request private data even if its handling failed, as it would never be freed otherwise. Fixes: 1b44c5a60c13 ("crypto: inside-secure - add SafeXcel EIP197 crypto engine driver") Suggested-by: Ofer Heifetz Signed-off-by: Antoine Tenart

[PATCH v4 1/4] crypto: inside-secure - per request invalidation

From: Ofer Heifetz When an invalidation request is needed we currently override the context .send and .handle_result helpers. This is wrong as under high load other requests can already be queued and overriding the context helpers will make them execute the wrong .send and

[PATCH v4 3/4] crypto: inside-secure - fix request allocations in invalidation path

This patch makes use of the SKCIPHER_REQUEST_ON_STACK and AHASH_REQUEST_ON_STACK helpers to allocate enough memory to contain both the crypto request structures and their embedded context (__ctx). Fixes: 1b44c5a60c13 ("crypto: inside-secure - add SafeXcel EIP197 crypto engine driver")

[PATCH v4 0/4] crypto: inside-secure - set of fixes

Hi Herbert, This series is a set of 4 fixes on the Inside Secure SafeXcel crypto engine driver. The series will be followed by another non-fix one. This is based on v4.15-rc3. Thanks, Antoine Since v3: - Added one patch to only update areq->result on final operations. - Fixed two coding

[PATCH v4 4/4] crypto: inside-secure - do not use areq->result for partial results

This patches update the SafeXcel driver to stop using the crypto ahash_request result field for partial results (i.e. on updates). Instead the driver local safexcel_ahash_req state field is used, and only on final operations the ahash_request result buffer is updated. Fixes: 1b44c5a60c13

Re: [PATCH 3/4] crypto: inside-secure - only update the result buffer when provided

On Mon, Dec 11, 2017 at 08:49:57AM +0100, Antoine Tenart wrote: > > So this patch is indeed fixing an issue, which should probably not be > there in the first place. I guess you recommend using a buffer local to > the driver instead, and only update areq->request on completion (final). That's one

Re: [PATCH 00/18] crypto: talitos - fixes and performance improvement

On Fri, Dec 08, 2017 at 03:20:40PM +, Horia Geantă wrote: > On 10/12/2017 6:20 PM, Herbert Xu wrote: > > On Fri, Oct 06, 2017 at 03:04:31PM +0200, Christophe Leroy wrote: > >> This serie fixes and improves the talitos crypto driver. > >> > >> First 6 patchs are fixes of failures reported by

Re: [PATCH v3 0/3] crypto: inside-secure - set of fixes

Hi, I'll send a v4 soon as there are two coding style issues in the series. I'll also include a new patch to only update the areq->result buffer on final operations (this will fix the issue I was trying to fix with "only update the result buffer when provided"). Sorry for the noise. Antoine On

[PATCH v3 1/3] crypto: inside-secure - per request invalidation

From: Ofer Heifetz When an invalidation request is needed we currently override the context .send and .handle_result helpers. This is wrong as under high load other requests can already be queued and overriding the context helpers will make them execute the wrong .send and

[PATCH v3 0/3] crypto: inside-secure - set of fixes

Hi Herbert, This series is a set of 4 fixes on the Inside Secure SafeXcel crypto engine driver. The series will be followed by another non-fix one. This is based on v4.15-rc3. Thanks, Antoine Since v2: - Removed the patch only update the result buffer when provided. Since v1: - Removed

[PATCH v3 2/3] crypto: inside-secure - free requests even if their handling failed

This patch frees the request private data even if its handling failed, as it would never be freed otherwise. Fixes: 1b44c5a60c13 ("crypto: inside-secure - add SafeXcel EIP197 crypto engine driver") Suggested-by: Ofer Heifetz Signed-off-by: Antoine Tenart

[PATCH v3 3/3] crypto: inside-secure - fix request allocations in invalidation path

This patch makes use of the SKCIPHER_REQUEST_ON_STACK and AHASH_REQUEST_ON_STACK helpers to allocate enough memory to contain both the crypto request structures and their embedded context (__ctx). Fixes: 1b44c5a60c13 ("crypto: inside-secure - add SafeXcel EIP197 crypto engine driver")