Re: [RFC PATCH v2 4/4] crypto: aes - add generic time invariant AES for CTR/CCM/GCM

On 2 February 2017 at 07:48, Ard Biesheuvel wrote: > On 2 February 2017 at 07:38, Eric Biggers wrote: >> Hi Ard, >> >> On Sat, Jan 28, 2017 at 11:33:33PM +, Ard Biesheuvel wrote: >>> >>> Note that this only implements AES encryption, which is

Re: [RFC PATCH] crypto: algapi - make crypto_xor() and crypto_inc() alignment agnostic

On 2 February 2017 at 06:47, Eric Biggers wrote: > On Mon, Jan 30, 2017 at 02:11:29PM +, Ard Biesheuvel wrote: >> Instead of unconditionally forcing 4 byte alignment for all generic >> chaining modes that rely on crypto_xor() or crypto_inc() (which may >> result in

Re: [RFC PATCH v2 4/4] crypto: aes - add generic time invariant AES for CTR/CCM/GCM

On 2 February 2017 at 07:38, Eric Biggers wrote: > Hi Ard, > > On Sat, Jan 28, 2017 at 11:33:33PM +, Ard Biesheuvel wrote: >> >> Note that this only implements AES encryption, which is all we need >> for CTR and CBC-MAC. AES decryption can easily be implemented in a >>

Re: [RFC PATCH v2 4/4] crypto: aes - add generic time invariant AES for CTR/CCM/GCM

Hi Ard, On Sat, Jan 28, 2017 at 11:33:33PM +, Ard Biesheuvel wrote: > > Note that this only implements AES encryption, which is all we need > for CTR and CBC-MAC. AES decryption can easily be implemented in a > similar way, but is significantly more costly. Is the expectation of decryption

Re: [RFC PATCH] crypto: algapi - make crypto_xor() and crypto_inc() alignment agnostic

On Mon, Jan 30, 2017 at 02:11:29PM +, Ard Biesheuvel wrote: > Instead of unconditionally forcing 4 byte alignment for all generic > chaining modes that rely on crypto_xor() or crypto_inc() (which may > result in unnecessary copying of data when the underlying hardware > can perform unaligned

Re: [PATCH 3/6] async_tx: Handle DMA devices having support for fewer PQ coefficients

On Wed, Feb 1, 2017 at 8:47 PM, Anup Patel wrote: > The DMAENGINE framework assumes that if PQ offload is supported by a > DMA device then all 256 PQ coefficients are supported. This assumption > does not hold anymore because we now have BCM-SBA-RAID offload engine >

Re: [PATCH -stable] crypto: ccm - deal with CTR ciphers that honour iv_out

On Wed, Feb 01, 2017 at 08:08:09PM +, Ard Biesheuvel wrote: > > Could you please forward this patch to Linus as well? I noticed that the patch Sure, I will do that. > crypto: arm64/aes-blk - honour iv_out requirement in CBC and CTR modes > > is now in mainline, which means CCM is now broken

Re: 4.10 aesni-intel no longer having lrw/ablk_helper dependencies?

On Wed, Feb 01, 2017 at 05:08:03PM +0100, Arkadiusz Miśkiewicz wrote: > > q: Will later loading of pcbc (so intel-aseni loaded from initrd, no pcbc > available, rootfs gets mounted; pcbc is loaded) enable its "functionality" > for > intel-aesni just like it would be available at intel-aesni

[PATCH 4/6] async_tx: Fix DMA_PREP_FENCE usage in do_async_gen_syndrome()

The DMA_PREP_FENCE is to be used when preparing Tx descriptor if output of Tx descriptor is to be used by next/dependent Tx descriptor. The DMA_PREP_FENSE will not be set correctly in do_async_gen_syndrome() when calling dma->device_prep_dma_pq() under following conditions: 1. ASYNC_TX_FENCE not

[PATCH 0/6] Broadcom SBA RAID support

The Broadcom SBA RAID is a stream-based device which provides RAID5/6 offload. It requires a SoC specific ring manager (such as Broadcom FlexRM ring manager) to provide ring-based programming interface. Due to this, the Broadcom SBA RAID driver (mailbox client) implements DMA device having one

[PATCH 5/6] dmaengine: Add Broadcom SBA RAID driver

The Broadcom stream buffer accelerator (SBA) provides offloading capabilities for RAID operations. This SBA offload engine is accessible via Broadcom SoC specific ring manager. This patch adds Broadcom SBA RAID driver which provides one DMA device with RAID capabilities using one or more Broadcom

[PATCH 3/6] async_tx: Handle DMA devices having support for fewer PQ coefficients

The DMAENGINE framework assumes that if PQ offload is supported by a DMA device then all 256 PQ coefficients are supported. This assumption does not hold anymore because we now have BCM-SBA-RAID offload engine which supports PQ offload with limited number of PQ coefficients. This patch extends

[PATCH 6/6] dt-bindings: Add DT bindings document for Broadcom SBA RAID driver

This patch adds the DT bindings document for newly added Broadcom SBA RAID driver. Signed-off-by: Anup Patel Reviewed-by: Ray Jui Reviewed-by: Scott Branden --- .../devicetree/bindings/dma/brcm,iproc-sba.txt | 29

[PATCH 2/6] lib/raid6: Add log-of-2 table for RAID6 HW requiring disk position

The raid6_gfexp table represents {2}^n values for 0 <= n < 256. The Linux async_tx framework pass values from raid6_gfexp as coefficients for each source to prep_dma_pq() callback of DMA channel with PQ capability. This creates problem for RAID6 offload engines (such as Broadcom SBA) which take

[PATCH 1/6] mailbox: Add new API mbox_channel_device() for clients

The remote processor can have DMAENGINE capabilities and client can pass data to be processed via main memory. In such cases, the client will require DMAble memory for remote processor. This patch adds new API mbox_channel_device() which can be used by clients to get struct device pointer of

Re: [PATCH v6 1/5] lib: Update LZ4 compressor module

On Tue, Jan 31, 2017 at 03:27:44PM -0700, Jonathan Corbet wrote: > On Fri, 27 Jan 2017 23:02:00 +0100 > Sven Schmidt <4ssch...@informatik.uni-hamburg.de> wrote: > > I have one quick question... > > > /* > > + * LZ4_compress_default() > > + * Compresses 'sourceSize' bytes from buffer 'source' >

Re: [PATCH -stable] crypto: ccm - deal with CTR ciphers that honour iv_out

On 28 January 2017 at 20:40, Ard Biesheuvel wrote: > The skcipher API mandates that chaining modes involving IVs calculate > an outgoing IV value that is suitable for encrypting additional blocks > of data. This means the CCM driver cannot assume that req->iv points to

Re: crypto: NULL deref in sha512_mb_mgr_get_comp_job_avx2

On Tue, Jan 31, 2017 at 02:16:31PM +0100, Dmitry Vyukov wrote: > Hello, > > I am getting the following reports with low frequency while running > syzkaller fuzzer. Unfortunately they are not reproducible and happen > in a background thread, so it is difficult to extract any context on > my side.

Re: [PATCH 1/1] crypto:algif_aead - Fix kernel panic on list_del

Am Mittwoch, 1. Februar 2017, 21:10:28 CET schrieb Harsh Jain: Hi Harsh, > Kernel panics when userspace program try to access AEAD interface. > Remove node from Linked List before freeing its memory. Very good catch. Thank you. Reviewed-by: Stephan Müller (PS: Herbert,

[PATCH 1/1] crypto:algif_aead - Fix kernel panic on list_del

Kernel panics when userspace program try to access AEAD interface. Remove node from Linked List before freeing its memory. Signed-off-by: Harsh Jain --- crypto/algif_aead.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/crypto/algif_aead.c

[PATCH] crypto: arm64/crc32 - merge CRC32 and PMULL instruction based drivers

The PMULL based CRC32 implementation already contains code based on the separate, optional CRC32 instructions to fallback to when operating on small quantities of data. We can expose these routines directly on systems that lack the 64x64 PMULL instructions but do implement the CRC32 ones, which

Re: [PATCH] crypto: arm64/crc32 - detect crc32 support in assembler

On 1 February 2017 at 13:58, Alexander Graf wrote: > On 02/01/2017 10:43 AM, Ard Biesheuvel wrote: >> >> On 1 February 2017 at 09:07, Ard Biesheuvel >> wrote: >>> >>> On 27 January 2017 at 10:52, Will Deacon wrote: On Fri,

Re: 4.10 aesni-intel no longer having lrw/ablk_helper dependencies?

On Mon, Jan 30, 2017 at 05:42:35PM +0100, Arkadiusz Miśkiewicz wrote: > On Monday 30 of January 2017, Eric Biggers wrote: > > > First, aesni-intel no longer includes an LRW implementation itself. > > Instead, the generic LRW module must be selected. Internally it will use > > the aesni-intel

Re: [PATCH] crypto: api - Clear CRYPTO_ALG_DEAD bit before registering an alg

On Mon, Jan 23, 2017 at 05:06:34PM +, Benedetto, Salvatore wrote: > > I forgot to add CC stable to it. > > This error was introduced in 4.8 and so I think it should go into stable 4.8 > and 4.9. > > Should I resend or can you add that? I had added it when applying the patch. Cheers, --

Re: [PATCH] crypto: tcrypt - Add mode to test specified algs

On Mon, Jan 23, 2017 at 04:13:04PM +0100, Rabin Vincent wrote: > > That's what I thought so too, but that doesn't seem to be the case. The > mode=0 handling is this: > > switch (m) { > case 0: > if (alg) { > if (!crypto_has_alg(alg, type, >

Re: [PATCH] crypto: arm64/crc32 - detect crc32 support in assembler

On 02/01/2017 10:43 AM, Ard Biesheuvel wrote: On 1 February 2017 at 09:07, Ard Biesheuvel wrote: On 27 January 2017 at 10:52, Will Deacon wrote: On Fri, Jan 27, 2017 at 10:43:16AM +, Ard Biesheuvel wrote: On 27 January 2017 at 10:40,

Re: [PATCH] crypto: arm64/crc32 - detect crc32 support in assembler

On 1 February 2017 at 09:07, Ard Biesheuvel wrote: > On 27 January 2017 at 10:52, Will Deacon wrote: >> On Fri, Jan 27, 2017 at 10:43:16AM +, Ard Biesheuvel wrote: >>> On 27 January 2017 at 10:40, Matthias Brugger wrote: >>>

Re: [PATCH] crypto: arm64/crc32 - detect crc32 support in assembler

On 27 January 2017 at 10:52, Will Deacon wrote: > On Fri, Jan 27, 2017 at 10:43:16AM +, Ard Biesheuvel wrote: >> On 27 January 2017 at 10:40, Matthias Brugger wrote: >> > Older compilers may not be able to detect the crc32 extended cpu type. >> >> What

Crypto Fixes for 4.10

Hi Linus: This push fixes a bug in CBC/CTR on ARM64 that breaks chaining as well as a bug in the core API that causes registration failures when a driver unloads and then reloads an algorithm. Please pull from git://git.kernel.org/pub/scm/linux/kernel/git/herbert/crypto-2.6.git linus Ard