[PATCH] crypto/mcryptd: Check mcryptd algorithm compatability

Algorithms not compatible with mcryptd could be spawned by mcryptd with a direct crypto_alloc_tfm invocation using a "mcryptd(alg)" name construct. This causes mcryptd to crash the kernel if "alg" is incompatible and not intended to be used with mcryptd. A flag CRYPTO_ALG_MCRYPT is being added

Re: Crash in crypto mcryptd

On Thu, 2016-12-01 at 19:00 -0500, Mikulas Patocka wrote: > Hi > > There is a bug in mcryptd initialization. > > This is a test module that tries various hash algorithms. When you load  > the module with "insmod test.ko 'alg=mcryptd(md5)'", the machine crashes. > > Mikulas > > Mikulas, Can

[PATCH] crypto: rsa - fix a potential race condition in build

When building kernel with RSA enabled with multithreaded, the below compile failure might be caught: | /buildarea/kernel-source/crypto/rsa_helper.c:18:28: fatal error: rsapubkey-asn1.h: No such file or directory | #include "rsapubkey-asn1.h" | ^ | compilation terminated. | CC

[PATCH v2 3/3] crypto: brcm: Add Broadcom SPU driver DT entry.

Add Northstar2 device tree entry for Broadcom Secure Processing Unit (SPU) crypto driver. Signed-off-by: Steve Lin Signed-off-by: Rob Rice --- arch/arm64/boot/dts/broadcom/ns2.dtsi | 12 1 file changed, 12 insertions(+) diff --git

[PATCH v2 1/3] crypto: brcm: DT documentation for Broadcom SPU driver

Device tree documentation for Broadcom Secure Processing Unit (SPU) crypto driver. Signed-off-by: Steve Lin Signed-off-by: Rob Rice --- .../devicetree/bindings/crypto/brcm,spu-crypto.txt | 25 ++ 1 file changed, 25

[PATCH v2 0/3] Add Broadcom SPU Crypto Driver

Change in v2: - select CRYPTO_DES in Kconfig The Broadcom SPU crypto driver provides access to SPU hardware for symmetric crypto offload. The driver supports ablkcipher, ahash, and aead operations. The driver supports several Broadcom SoCs with different revisions of the SPU hardware. The driver

Re: Crash in crypto mcryptd

On Thu, 2016-12-01 at 23:06 -0800, Eric Biggers wrote: > On Thu, Dec 01, 2016 at 05:47:02PM -0800, Tim Chen wrote: > > > > On Thu, 2016-12-01 at 19:00 -0500, Mikulas Patocka wrote: > > > > > > Hi > > > > > > There is a bug in mcryptd initialization. > > > > > > This is a test module that tries

Re: [PATCH 1/2] crypto: marvell - Don't copy hash operation twice into the SRAM

On Fri, 2 Dec 2016 17:05:50 +0100 Romain Perier wrote: > No need to copy the template of an hash operation twice into the SRAM > from the step function. > > Fixes: commit 85030c5168f1 ("crypto: marvell - Add support for chai...") > Signed-off-by: Romain Perier

Re: [PATCH 1/2] crypto: marvell - Don't copy hash operation twice into the SRAM

On Fri, 2 Dec 2016 17:05:50 +0100 Romain Perier wrote: > No need to copy the template of an hash operation twice into the SRAM > from the step function. > > Fixes: commit 85030c5168f1 ("crypto: marvell - Add support for chai...") > Signed-off-by: Romain Perier

Re: [PATCH 2/2] crypto: marvell - Don't corrupt state of an STD req for re-stepped ahash

On Fri, 2 Dec 2016 17:05:51 +0100 Romain Perier wrote: > mv_cesa_hash_std_step always copies creq->state into the SRAM. If an IRQ > is triggered while the current STD request is not finished, this request > will be stepped again and the initial state will be

[PATCH 1/2] crypto: marvell - Don't copy hash operation twice into the SRAM

No need to copy the template of an hash operation twice into the SRAM from the step function. Fixes: commit 85030c5168f1 ("crypto: marvell - Add support for chai...") Signed-off-by: Romain Perier --- drivers/crypto/marvell/hash.c | 3 --- 1 file changed, 3

[PATCH 2/2] crypto: marvell - Don't corrupt state of an STD req for re-stepped ahash

mv_cesa_hash_std_step always copies creq->state into the SRAM. If an IRQ is triggered while the current STD request is not finished, this request will be stepped again and the initial state will be filled into the engine. This commit changes the function in order to copy the state only when the

[PATCH 0/2] CESA: Fixes for STD ahash requests

This set of patches fixes two issues for STD ahash requests. The first one is that the operation template is copied twice to the SRAM from the step function, it is not needed. The second one is also contained in the step function which copies creq->state to the engine for all type of requests ,

Re: [PATCH] crypto: marvell - Don't copy hash operation twice into the SRAM

Hello, Le 02/12/2016 à 09:58, Romain Perier a écrit : Hi, Le 01/12/2016 à 17:27, Gregory CLEMENT a écrit : Hi Romain, On jeu., déc. 01 2016, Romain Perier wrote: No need to copy the template of an hash operation twice into the SRAM from the step

[PATCH v3] crypto: AF_ALG - fix AEAD tag memory handling

Hi Herbert, Mat, as Herbert nacked the patch to disregard the AD in the destination buffer, there will be no user space visible buffer length changes apart from the patch below. Therefore, I would like to suggest to include the patch now. The change for the AD copy-over will come in the next

Re: [PATCH 1/2] Add crypto driver support for some MediaTek chips

Hello, On Fri, 2016-12-02 at 09:18 +0100, Corentin Labbe wrote: > Hello > > I have some minor comment inline > > On Fri, Dec 02, 2016 at 11:26:44AM +0800, Ryder Lee wrote: > > This adds support for the MediaTek hardware accelerator on > > mt7623/mt2701/mt8521p SoC. > > > > This driver

Re: [PATCH] crypto: marvell - Don't copy hash operation twice into the SRAM

Hi, Le 01/12/2016 à 17:27, Gregory CLEMENT a écrit : Hi Romain, On jeu., déc. 01 2016, Romain Perier wrote: No need to copy the template of an hash operation twice into the SRAM from the step function. Does this patch fix a bug ot it is jsute a

Re: [PATCH 1/2] Add crypto driver support for some MediaTek chips

Hello I have some minor comment inline On Fri, Dec 02, 2016 at 11:26:44AM +0800, Ryder Lee wrote: > This adds support for the MediaTek hardware accelerator on > mt7623/mt2701/mt8521p SoC. > > This driver currently implement: > - SHA1 and SHA2 family(HMAC) hash alogrithms. > - AES block cipher