RE: [PATCH] crypto: caam - fix pointer size for AArch64 boot loader, AArch32 kernel

> -Original Message- > From: Horia Geantă [mailto:horia.gea...@nxp.com] > Sent: Monday, December 05, 2016 5:07 PM > To: Herbert Xu > Cc: David S. Miller ; linux-crypto@vger.kernel.org; > Dan Douglass ; Alison Wang

[PATCH v2] crypto/mcryptd: Check mcryptd algorithm compatibility

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 an arbitrary "alg" is incompatible and not intended to be used with mcryptd. It is an issue if AF_ALG

Re: [PATCH] crypto/mcryptd: Check mcryptd algorithm compatability

On Mon, 2016-12-05 at 08:50 -0800, Tim Chen wrote: > On Mon, 2016-12-05 at 20:34 +0800, Herbert Xu wrote: > > > > On Fri, Dec 02, 2016 at 04:15:21PM -0800, Tim Chen wrote: > > > > > > > > > Algorithms not compatible with mcryptd could be spawned by mcryptd > > > with a direct crypto_alloc_tfm

[PATCH v3 3/6] crypto: arm64/crct10dif - port x86 SSE implementation to arm64

This is a transliteration of the Intel algorithm implemented using SSE and PCLMULQDQ instructions that resides in the file arch/x86/crypto/crct10dif-pcl-asm_64.S, but simplified to only operate on buffers that are 16 byte aligned (but of any size) Signed-off-by: Ard Biesheuvel

[PATCH v3 4/6] crypto: arm/crct10dif - port x86 SSE implementation to ARM

This is a transliteration of the Intel algorithm implemented using SSE and PCLMULQDQ instructions that resides in the file arch/x86/crypto/crct10dif-pcl-asm_64.S, but simplified to only operate on buffers that are 16 byte aligned (but of any size) Signed-off-by: Ard Biesheuvel

[PATCH v3 6/6] crypto: arm/crc32 - accelerated support based on x86 SSE implementation

This is a combination of the the Intel algorithm implemented using SSE and PCLMULQDQ instructions from arch/x86/crypto/crc32-pclmul_asm.S, and the new CRC32 extensions introduced for both 32-bit and 64-bit ARM in version 8 of the architecture. Two versions of the above combo are provided, one for

[PATCH v3 5/6] crypto: arm64/crc32 - accelerated support based on x86 SSE implementation

This is a combination of the the Intel algorithm implemented using SSE and PCLMULQDQ instructions from arch/x86/crypto/crc32-pclmul_asm.S, and the new CRC32 extensions introduced for both 32-bit and 64-bit ARM in version 8 of the architecture. Two versions of the above combo are provided, one for

[PATCH v3 0/6] crypto: ARM/arm64 CRC-T10DIF/CRC32/CRC32C roundup

This v3 combines the CRC-T10DIF and CRC32 implementations for both ARM and arm64 that I sent out a couple of weeks ago, and adds support to the latter for CRC32C. Changes since v2: - fix a couple of big-endian bugs in CRC32/CRC32C - add back handling to the CRC-T10DIF routines of buffers that are

[PATCH v3 2/6] crypto: testmgr - add/enhance test cases for CRC-T10DIF

The existing test cases only exercise a small slice of the various possible code paths through the x86 SSE/PCLMULQDQ implementation, and the upcoming ports of it for arm64. So add one that exceeds 256 bytes in size, and convert another to a chunked test. Signed-off-by: Ard Biesheuvel

[PATCH v3 1/6] crypto: testmgr - avoid overlap in chunked tests

The IDXn offsets are chosen such that tap values (which may go up to 255) end up overlapping in the xbuf allocation. In particular, IDX1 and IDX3 are too close together, so update IDX3 to avoid this issue. Signed-off-by: Ard Biesheuvel --- crypto/testmgr.c | 2 +- 1

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

On 12/4/2016 10:48 PM, Herbert Xu wrote: On Fri, Dec 02, 2016 at 03:41:04PM -0800, Yang Shi wrote: 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

Re: [PATCH] crypto/mcryptd: Check mcryptd algorithm compatability

On Mon, 2016-12-05 at 20:34 +0800, Herbert Xu wrote: > On Fri, Dec 02, 2016 at 04:15:21PM -0800, Tim Chen wrote: > > > > 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

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

Hi Herbert, Changes v4: restore the old behavior -- if the caller does not provide sufficient output buffer size, return an error. ---8<--- For encryption, the AEAD ciphers require AAD || PT as input and generate AAD || CT || Tag as output and vice versa for decryption. Prior to this patch,

Loan Offer

We can help you with a genuine loan to meet your needs. Do you need a personal or business loan without stress and quick approval? Do you need an urgent loan today? No Credit Checks * LOAN APPROVAL IN 60MINS !! * GUARANTEED SAME DAY TRANSFER !! * 100% APPROVAL RATE !! * LOW INTEREST RATE !!

Re: [PATCH v2] crypto: sun4i-ss: support the Security System PRNG

On Mon, Dec 05, 2016 at 08:37:05PM +0800, Herbert Xu wrote: > On Mon, Dec 05, 2016 at 11:48:42AM +0100, Corentin Labbe wrote: > > From: LABBE Corentin > > > > The Security System have a PRNG. > > This patch add support for it as an hwrng. > > > > Signed-off-by:

Re: [PATCH v2] crypto: sun4i-ss: support the Security System PRNG

On Mon, Dec 05, 2016 at 11:48:42AM +0100, Corentin Labbe wrote: > From: LABBE Corentin > > The Security System have a PRNG. > This patch add support for it as an hwrng. > > Signed-off-by: Corentin Labbe Please don't add PRNGs to hwrng. If

Re: [PATCH] crypto/mcryptd: Check mcryptd algorithm compatability

On Fri, Dec 02, 2016 at 04:15:21PM -0800, Tim Chen wrote: > 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

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

On Fri, Dec 02, 2016 at 03:16:26PM +0100, Stephan Mueller wrote: > > In addition, the code now handles the situation where the provided > output buffer is too small by reducing the size of the processed > input buffer accordingly. Due to this handling, he changes are I think that's dangerous.

[PATCH v2] crypto: sun4i-ss: support the Security System PRNG

From: LABBE Corentin The Security System have a PRNG. This patch add support for it as an hwrng. Signed-off-by: Corentin Labbe --- Changes since v1: - Replaced all spin_lock_bh by simple spin_lock - Removed handling of size not modulo 4

Re: [PATCH v1 2/2] crypto: mediatek - add DT bindings documentation

On 05/12/16 08:01, Ryder Lee wrote: Add DT bindings documentation for the crypto driver Signed-off-by: Ryder Lee --- .../devicetree/bindings/crypto/mediatek-crypto.txt | 32 ++ 1 file changed, 32 insertions(+) create mode 100644

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

Hello I have two minor comment. On Mon, Dec 05, 2016 at 03:01:23PM +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. There is a typo for

Re: [PATCH v2 0/6] crypto: ARM/arm64 CRC-T10DIF/CRC32/CRC32C roundup

On 4 December 2016 at 11:54, Ard Biesheuvel wrote: > This v2 combines the CRC-T10DIF and CRC32 implementations for both ARM and > arm64 that I sent out a couple of weeks ago, and adds support to the latter > for CRC32C. > Please don't apply yet. There is an issue in

[PATCH] crypto: caam - fix pointer size for AArch64 boot loader, AArch32 kernel

Start with a clean slate before dealing with bit 16 (pointer size) of Master Configuration Register. This fixes the case of AArch64 boot loader + AArch32 kernel, when the boot loader might set MCFGR[PS] and kernel would fail to clear it. Cc: Reported-by: Alison Wang

[PATCH v2 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,

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

mv_cesa_hash_std_step() copies the creq->state into the SRAM at each step, but this is only required on the first one. By doing that, we overwrite the engine state, and get erroneous results when the crypto request is split in several chunks to fit in the internal SRAM. This commit changes the

[PATCH v2 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 Cc: --- drivers/crypto/marvell/hash.c |