Applying, thanks!--b.
On Wed, Mar 28, 2018 at 10:57:22AM -0700, Eric Biggers wrote:
> make_checksum_hmac_md5() is allocating an HMAC transform and doing
> crypto API calls in the following order:
>
> crypto_ahash_init()
> crypto_ahash_setkey()
> crypto_ahash_digest()
>
> This is wron
On Wed, 2018-03-28 at 23:27 +0530, Varsha Rao wrote:
> This patch fixes the clang warning of extraneous parentheses, with the
> following coccinelle script.
>
> @@
> identifier i;
> constant c;
> @@
> (
> -((i == c))
> +i == c
> >
>
> -((i <= c))
> +i <= c
Why just the "==" and "<=" cases?
Why
make_checksum_hmac_md5() is allocating an HMAC transform and doing
crypto API calls in the following order:
crypto_ahash_init()
crypto_ahash_setkey()
crypto_ahash_digest()
This is wrong because it makes no sense to init() the request before a
key has been set, given that the initial s
This patch fixes the clang warning of extraneous parentheses, with the
following coccinelle script.
@@
identifier i;
constant c;
@@
(
-((i == c))
+i == c
|
-((i <= c))
+i <= c
)
Signed-off-by: Varsha Rao
---
drivers/crypto/cavium/zip/zip_regs.h | 42 ++--
1 file
There are two IV-related issues:
(1) crypto API does not guarantee to provide an IV buffer that is DMAable,
thus it's incorrect to DMA map it
(2) for in-place decryption, since ciphertext is overwritten with
plaintext, updated IV (req->info) will contain the last block of plaintext
(instead of the
There are two IV-related issues:
(1) crypto API does not guarantee to provide an IV buffer that is DMAable,
thus it's incorrect to DMA map it
(2) for in-place decryption, since ciphertext is overwritten with
plaintext, updated req->info will contain the last block of plaintext
(instead of the last
This patch set fixes several issues related to IV handling:
-in some cases IV direction is incorrect
-IVs need to be DMA mapped (when they are not provided directly
as "immediate" values in the descriptors); however, crypto API does not
guarantee the IV buffers to be DMAable
-in-place ablkcipher de
In case of GIVCIPHER, IV is generated by the device.
Fix the DMA mapping direction.
Cc: # 3.19+
Fixes: 7222d1a34103 ("crypto: caam - add support for givencrypt cbc(aes) and
rfc3686(ctr(aes))")
Signed-off-by: Horia Geantă
---
drivers/crypto/caam/caamalg.c | 29 +
1 f
On Wed, Mar 28, 2018 at 05:41:30PM +0200, Stefan Agner wrote:
>
> Herbert, given that Raveendra agrees to the change, do you want me to
> send a non-RFC version or can you merge the patch as is?
There is no need to resend it.
Thanks,
--
Email: Herbert Xu
Home Page: http://gondor.apana.org.au/~h
On 28.03.2018 08:38, Raveendra Padasalagi wrote:
> Hi Stefan,
>
> The change looks to be fine. From the IP point of view its using the
> same values in case of AES cipher and hash types so explicit casting
> should be ok.
Can I take that as an Ack?
Herbert, given that Raveendra agrees to the ch
static function declarations don't belong in a header file, as shown
by this compiler warning:
In file included from /git/arm-soc/drivers/crypto/chelsio/chcr_ipsec.c:66:
drivers/crypto/chelsio/chcr_crypto.h:343:12: error: 'chcr_ahash_continue'
declared 'static' but never defined [-Werror=unused-f
Enabling virtual mapped kernel stacks breaks the thunderx_zip
driver. On compression or decompression the executing CPU hangs
in an endless loop. The reason for this is the usage of __pa
by the driver which does no longer work for an address that is
not part of the 1:1 mapping.
The zip driver allo
After issuing a request an endless loop was used to read the
completion state from memory which is asynchronously updated
by the ZIP coprocessor.
Add an upper bound to the retry attempts to prevent a CPU getting stuck
forever in case of an error. Additionally, add a read memory barrier
and a small
13 matches
Mail list logo
