talitos_edesc and talitos_request structures are moved to crypto
request private context.
This avoids allocating memory in the driver in the cases when data
(assoc, in, out) is not scattered.
It is also an intermediary step towards adding backlogging support.
Signed-off-by: Horia Geanta
On 03/13/2015 12:16 PM, Horia Geanta wrote:
I was running into situations where the hardware FIFO was filling up, and
the code was returning EAGAIN to dm-crypt and just dropping the submitted
crypto request.
This adds support in talitos for a software backlog queue. When requests
can't be
Some crypto backends might require the requests' private contexts
to be allocated in DMA-able memory.
Signed-off-by: Horia Geanta horia.gea...@freescale.com
---
Depends on patch 1/4 (sent only on crypto list) that adds the
CRYPTO_TFM_REQ_DMA flag.
net/ipv4/esp4.c | 7 ++-
net/ipv6/esp6.c |
talitos_edesc and talitos_request structures are moved to crypto
request private context.
This avoids allocating memory in the driver in the cases when data
(assoc, in, out) is not scattered.
It is also an intermediary step towards adding backlogging support.
Signed-off-by: Horia Geanta
The CRYPTO_TFM_REQ_DMA flag can be used by backend implementations to
indicate to crypto API the need to allocate GFP_DMA memory
for private contexts of the crypto requests.
Signed-off-by: Horia Geanta horia.gea...@freescale.com
---
include/linux/crypto.h | 9 +
1 file changed, 9
The CRYPTO_TFM_REQ_DMA flag can be used by backend implementations to
indicate to crypto API the need to allocate GFP_DMA memory
for private contexts of the crypto requests.
Signed-off-by: Horia Geanta horia.gea...@freescale.com
---
include/crypto/hash.h | 4
include/linux/crypto.h | 9
I was running into situations where the hardware FIFO was filling up, and
the code was returning EAGAIN to dm-crypt and just dropping the submitted
crypto request.
This adds support in talitos for a software backlog queue. When requests
can't be queued to the hardware immediately EBUSY is
I was running into situations where the hardware FIFO was filling up, and
the code was returning EAGAIN to dm-crypt and just dropping the submitted
crypto request.
This adds support in talitos for a software backlog queue. When requests
can't be queued to the hardware immediately EBUSY is
Some crypto backends might require the requests' private contexts
to be allocated in DMA-able memory.
Signed-off-by: Horia Geanta horia.gea...@freescale.com
---
Depends on patch 1/4 (sent only on crypto list) that adds the
CRYPTO_TFM_REQ_DMA flag.
net/ipv4/esp4.c | 7 ++-
net/ipv6/esp6.c |
On 3/13/2015 7:14 PM, Horia Geanta wrote:
The CRYPTO_TFM_REQ_DMA flag can be used by backend implementations to
indicate to crypto API the need to allocate GFP_DMA memory
for private contexts of the crypto requests.
Signed-off-by: Horia Geanta horia.gea...@freescale.com
---
Hi,
Several hardware related cipher implementations are implemented as follows: a
helper cipher implementation is registered with the kernel crypto API.
Such helper ciphers are never intended to be called by normal users. In some
cases, calling them via the normal crypto API may even cause
fixing a syntax-error .
Signed-off-by : Ameen Ali ameenali...@gmail.com
---
arch/x86/crypto/sha-mb/sha1_mb.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/x86/crypto/sha-mb/sha1_mb.c b/arch/x86/crypto/sha-mb/sha1_mb.c
index fd9f6b0..ec0b989 100644
---
From: Horia Geanta horia.gea...@freescale.com
Date: Fri, 13 Mar 2015 19:15:22 +0200
Some crypto backends might require the requests' private contexts
to be allocated in DMA-able memory.
Signed-off-by: Horia Geanta horia.gea...@freescale.com
No way.
Upper layers should be absolutely not
On Fri, 2015-03-13 at 23:13 +0200, Ameen Ali wrote:
fixing a syntax-error .
Signed-off-by : Ameen Ali ameenali...@gmail.com
---
arch/x86/crypto/sha-mb/sha1_mb.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/x86/crypto/sha-mb/sha1_mb.c
fixing a syntax-error .
Signed-off-by : Ameen Ali ameenali...@gmail.com
---
arch/x86/crypto/sha-mb/sha1_mb.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/x86/crypto/sha-mb/sha1_mb.c b/arch/x86/crypto/sha-mb/sha1_mb.c
index fd9f6b0..ec0b989 100644
---
On Wed, Mar 11, 2015 at 01:11:07PM +0100, Alexander Bergmann wrote:
From 0c7233769665f03e9f91342770dba7279f928c23 Mon Sep 17 00:00:00 2001
From: Stephan Mueller smuel...@chronox.de
Date: Tue, 10 Mar 2015 17:00:36 +0100
Subject: [PATCH] crypto: testmgr - fix RNG return code enforcement
Due
Due to the change to RNGs to always return zero in success case, the RNG
interface must zeroize the buffer with the length provided by the
caller.
Signed-off-by: Stephan Mueller smuel...@chronox.de
---
crypto/algif_rng.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git
On Wed, Mar 11, 2015 at 03:29:35PM +1100, Andre Wolokita wrote:
In omap4_rng_init(), a check of bit 10 of the RNG_CONFIG_REG is done to
determine
whether the RNG is running. This is suspicious firstly due to the use of
RNG_CONTROL_ENABLE_TRNG_MASK and secondly because the same mask is written
On Wed, Mar 11, 2015 at 07:45:35AM +0100, Stephan Mueller wrote:
Due to the change to RNGs to always return zero in success case, the RNG
interface must zeroize the buffer with the length provided by the
caller.
Signed-off-by: Stephan Mueller smuel...@chronox.de
Your patch is line-wrapped
On Thu, Mar 12, 2015 at 09:17:51AM +0100, Stephan Mueller wrote:
The kernel crypto API logic requires the caller to provide the
length of (ciphertext || authentication tag) as cryptlen for the
AEAD decryption operation. Thus, the cipher implementation must
calculate the size of the plaintext
On Wed, Mar 11, 2015 at 05:56:26PM +0100, Julia Lawall wrote:
From: Julia Lawall julia.law...@lip6.fr
The semantic patch that fixes this problem is as follows:
(http://coccinelle.lip6.fr/)
// smpl
@r@
type T;
identifier f;
@@
static T f (...) { ... }
@@
identifier r.f;
declarer
Hi Horia,
On Wed, Mar 11, 2015 at 11:48 AM, Horia Geantă
horia.gea...@freescale.com wrote:
While here: note that xts-talitos supports only two key lengths - 256
and 512 bits. There are tcrypt speed tests that check also for 384-bit
keys (which is out-of-spec, but still...), leading to a Key
22 matches
Mail list logo
