fixing a syntax-error .
Signed-off-by : Ameen Ali
---
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
--- a/arch/x86/crypto/sha-mb/sha1_mb.c
+++
On Fri, 2015-03-13 at 23:13 +0200, Ameen Ali wrote:
> fixing a syntax-error .
>
> Signed-off-by : Ameen Ali
> ---
> 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
>
fixing a syntax-error .
Signed-off-by : Ameen Ali
---
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
--- a/arch/x86/crypto/sha-mb/sha1_mb.c
+++
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 fa
From: Horia Geanta
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
No way.
Upper layers should be absolutely not required to know about such
requirements.
Such deta
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 queued
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
---
dr
Some crypto backends might require the requests' private contexts
to be allocated in DMA-able memory.
Signed-off-by: Horia Geanta
---
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 | 7 ++-
2 files changed
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 returned
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
---
include/crypto/hash.h | 4
include/linux/crypto.h | 9 +
2 files changed, 13
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
---
dr
Some crypto backends might require the requests' private contexts
to be allocated in DMA-able memory.
Signed-off-by: Horia Geanta
---
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 | 7 ++-
2 files changed
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 returned
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
> ---
ahash_request_alloc() update is miss
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
---
include/linux/crypto.h | 9 +
1 file changed, 9 insertions(+)
diff --git a/includ
Hi Horia,
On Wed, Mar 11, 2015 at 11:48 AM, Horia Geantă
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 Size Error"
> - see bel
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
---
crypto/algif_rng.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/crypto/algif_rng.c b/crypto
On Wed, Mar 11, 2015 at 05:56:26PM +0100, Julia Lawall wrote:
> From: Julia Lawall
>
> The semantic patch that fixes this problem is as follows:
> (http://coccinelle.lip6.fr/)
>
> //
> @r@
> type T;
> identifier f;
> @@
>
> static T f (...) { ... }
>
> @@
> identifier r.f;
> declarer name EXP
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
> Date: Tue, 10 Mar 2015 17:00:36 +0100
> Subject: [PATCH] crypto: testmgr - fix RNG return code enforcement
>
> Due to the change t
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 plaintex
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
Your patch is line-wrapped and doesn't appl
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 writ
22 matches
Mail list logo
