On Wed, Dec 20, 2017 at 07:23:31AM +, Gilad Ben-Yossef wrote:
> Fix declaration, implementation and wrapper function to use
> the same size_t type we actually define the parameter to be.
>
> Fixes: 3f268f5d6669 ("staging: ccree: turn compile time debug log to params")
> Signed-off-by: Gilad Be
Fix declaration, implementation and wrapper function to use
the same size_t type we actually define the parameter to be.
Fixes: 3f268f5d6669 ("staging: ccree: turn compile time debug log to params")
Signed-off-by: Gilad Ben-Yossef
---
drivers/staging/ccree/ssi_driver.c | 2 +-
drivers/staging/cc
There are no init and exit callbacks, so delete its comments.
Signed-off-by: Zhou Wang
---
include/crypto/internal/scompress.h | 11 ---
1 file changed, 11 deletions(-)
diff --git a/include/crypto/internal/scompress.h
b/include/crypto/internal/scompress.h
index ccad9b2..0f6ddac 100644
The aesni_gcm_enc/dec functions can access memory before the start of
the data buffer if the length of the data buffer is less than 16 bytes.
This is because they perform the read via a single 16-byte load. This
can potentially result in accessing a page that is not mapped and thus
causing the mach
The aesni_gcm_enc/dec functions can access memory after the end of
the AAD buffer if the AAD length is not a multiple of 4 bytes.
It didn't matter with rfc4106-gcm-aesni as in that case the AAD was
always followed by the 8 byte IV, but that is no longer the case with
generic-gcm-aesni. This can pot
Changes in v2:
- Also fixed issue 2 described below in addition to issue 1 in v1
The aesni_gcm_enc/dec functions can access memory before the start or end of
the supplied src buffer. This can happen if either:
1. The data length is less than 16 bytes and there is no AAD or the AAD
On Mon, Dec 18, 2017 at 04:40:26PM -0800, Eric Biggers wrote:
> From: Eric Biggers
>
> Using %rbp as a temporary register breaks frame pointer convention and
> breaks stack traces when unwinding from an interrupt in the crypto code.
>
> In twofish-3way, we can't simply replace %rbp with another
The aesni_gcm_enc/dec functions can access memory before the start of
the data buffer if the length of the data buffer is less than 16 bytes.
This is because they perform the read via a single 16-byte load. It
didn't matter with rfc4106-gcm-aesni as in that case there was always at
least 16 bytes p
From: Jan Engelhardt
Date: Tue, 19 Dec 2017 19:09:07 +0100
> queue_cache_init is first called for the Control Word Queue
> (n2_crypto_probe). At that time, queue_cache[0] is NULL and a new
> kmem_cache will be allocated. If the subsequent n2_register_algs call
> fails, the kmem_cache will be rele
queue_cache_init is first called for the Control Word Queue
(n2_crypto_probe). At that time, queue_cache[0] is NULL and a new
kmem_cache will be allocated. If the subsequent n2_register_algs call
fails, the kmem_cache will be released in queue_cache_destroy, but
queue_cache_init[0] is not set back
On 12/17/2017 03:49 AM, PrasannaKumar Muralidharan wrote:
On 17 December 2017 at 14:53, PrasannaKumar Muralidharan
wrote:
Hi Gary,
Some minor comments below.
On 16 December 2017 at 01:25, Gary R Hook wrote:
Commit 142a27f0a731 added support for a "best" RNG, and in doing so
introduced a ha
* Ingo Molnar wrote:
>
> * Eric Biggers wrote:
>
> > There may be a small overhead caused by replacing 'xchg REG, REG' with
> > the needed sequence 'mov MEM, REG; mov REG, MEM; mov REG, REG' once per
> > round. But, counterintuitively, when I tested "ctr-twofish-3way" on a
> > Haswell proces
From: Jan Engelhardt
Date: Tue, 19 Dec 2017 16:42:39 +0100 (CET)
> Nevertheless, I think that the error pathing in n2_core.c should be made
> robust as well.
I completely agree.
> Should I resubmit with a new commit message?
Yes.
On Tuesday 2017-12-19 16:31, David Miller wrote:
>
>Instead, what fails is the algorithm registry which you should look
>more deeply into the cause of.
You are right. The registration failure is because the crypto layer
expects halg->statesize to be non-zero, and drivers/crypto/n2_core.c
does n
From: Juergen Gross
> Sent: 19 December 2017 08:05
..
>
> Exchanging 2 registers can be done without memory access via:
>
> xor reg1, reg2
> xor reg2, reg1
> xor reg1, reg2
That'll generate horrid data dependencies.
ISTR that there are some optimisations for the stack,
so even 'push reg1', 'mov
Am Dienstag, 19. Dezember 2017, 12:26:42 CET schrieb Jonathan Cameron:
Hi Jonathan,
> > > + atomic_set(&ctx->rcvused, 0);
> >
> > I think ATOMIC_INIT(0) is more suitable here.
>
> It's ugly to use it to assign a dynamic element like this.
>
> ctx->rcvused = (atomic_t)ATOMIC_INIT(0);
You are r
On Tue, 19 Dec 2017 12:11:19 +0100
Stephan Mueller wrote:
> Am Dienstag, 19. Dezember 2017, 11:31:22 CET schrieb Jonathan Cameron:
>
> Hi Jonathan,
>
> > This variable was increased and decreased without any protection.
> > Result was an occasional misscount and negative wrap around resulting
>
Am Dienstag, 19. Dezember 2017, 11:31:22 CET schrieb Jonathan Cameron:
Hi Jonathan,
> This variable was increased and decreased without any protection.
> Result was an occasional misscount and negative wrap around resulting
> in false resource allocation failures.
>
> Signed-off-by: Jonathan Cam
Sorry idiot moment. Sent that out with our internal markings.
Resending shortly.
On Tue, 19 Dec 2017 10:27:24 +
Jonathan Cameron wrote:
> This variable was increased and decreased without any protection.
> Result was an occasional misscount and negative wrap around resulting
> in false reso
This variable was increased and decreased without any protection.
Result was an occasional misscount and negative wrap around resulting
in false resource allocation failures.
Signed-off-by: Jonathan Cameron
Fixes: 2d97591ef43d ("crypto: af_alg - consolidation of duplicate code")
---
The fixes tag
Save Era in driver's private data for further usage,
like deciding whether an erratum applies or a feature is available
based on its value.
Signed-off-by: Horia Geantă
---
drivers/crypto/caam/ctrl.c | 4 +++-
drivers/crypto/caam/intern.h | 1 +
2 files changed, 4 insertions(+), 1 deletion(-)
Offload split key generation in CAAM engine, using DKP.
DKP is supported starting with Era 6.
Note that the way assoclen is transmitted from the job descriptor
to the shared descriptor changes - DPOVRD register is used instead
of MATH3 (where available), since DKP protocol thrashes the MATH
regist
Key data is not modified, it is copied in the shared descriptor.
Signed-off-by: Horia Geantă
---
drivers/crypto/caam/caamalg_desc.c | 6 +++---
drivers/crypto/caam/desc_constr.h | 10 +-
2 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/drivers/crypto/caam/caamalg_desc.c
ablkcipher shared descriptors are relatively small, thus there is enough
space for the key to be inlined.
Accordingly, there is no need to copy the key in ctx->key.
Signed-off-by: Horia Geantă
---
drivers/crypto/caam/caamalg.c| 8 ++--
drivers/crypto/caam/caamalg_qi.c | 8 ++--
2 fil
On 19/12/17 08:54, Ingo Molnar wrote:
>
> * Eric Biggers wrote:
>
>> There may be a small overhead caused by replacing 'xchg REG, REG' with
>> the needed sequence 'mov MEM, REG; mov REG, MEM; mov REG, REG' once per
>> round. But, counterintuitively, when I tested "ctr-twofish-3way" on a
>> Hasw
25 matches
Mail list logo
