linux.git/drivers/crypto/marvell, branch v4.9.30

crypto: marvell - Don't corrupt state of an STD req for re-stepped ahash

2016-12-07T11:55:17+00:00

mv_cesa_hash_std_step() copies the creq->state into the SRAM at each
step, but this is only required on the first one. By doing that, we
overwrite the engine state, and get erroneous results when the crypto
request is split in several chunks to fit in the internal SRAM.

This commit changes the function to copy the state only on the first
step.

Fixes: commit 2786cee8e50b ("crypto: marvell - Move SRAM I/O op...")
Signed-off-by: Romain Perier 
Cc: 
Signed-off-by: Herbert Xu

crypto: marvell - Don't copy hash operation twice into the SRAM

2016-12-07T11:55:16+00:00

No need to copy the template of an hash operation twice into the SRAM
from the step function.

Fixes: commit 85030c5168f1 ("crypto: marvell - Add support for chai...")
Signed-off-by: Romain Perier 
Cc: 
Signed-off-by: Herbert Xu

crypto: marvell - Don't hardcode block size in mv_cesa_ahash_cache_req

2016-08-09T10:47:31+00:00

Don't use 64 'as is', as max block size in mv_cesa_ahash_cache_req. Use
CESA_MAX_HASH_BLOCK_SIZE instead, this is better for readability.

Signed-off-by: Romain Perier 
Signed-off-by: Herbert Xu

crypto: marvell - Don't overwrite default creq->state during initialization

2016-08-09T10:47:31+00:00

Currently, in mv_cesa_{md5,sha1,sha256}_init creq->state is initialized
before the call to mv_cesa_ahash_init. This is wrong because this
function fills creq with zero by using memset, so its 'state' that
contains the default DIGEST is overwritten. This commit fixes the issue
by initializing creq->state just after the call to mv_cesa_ahash_init.

Fixes: commit b0ef51067cb4 ("crypto: marvell/cesa - initialize hash...")
Signed-off-by: Romain Perier 
Signed-off-by: Herbert Xu

crypto: marvell - Update transformation context for each dequeued req

2016-08-09T10:47:30+00:00

So far, sub part of mv_cesa_int was responsible of dequeuing complete
requests, then call the 'cleanup' operation on these reqs and call the
crypto api callback 'complete'. The problem is that the transformation
context 'ctx' is retrieved only once before the while loop. Which means
that the wrong 'cleanup' operation might be called on the wrong type of
cesa requests, it can lead to memory corruptions with this message:

marvell-cesa f1090000.crypto: dma_pool_free cesa_padding, 5a5a5a5a/5a5a5a5a (bad dma)

This commit fixes the issue, by updating the transformation context for
each dequeued cesa request.

Fixes: commit 85030c5168f1 ("crypto: marvell - Add support for chai...")
Signed-off-by: Romain Perier 
Signed-off-by: Herbert Xu

crypto: marvell - make mv_cesa_ahash_cache_req() return bool

2016-08-09T10:47:30+00:00

The mv_cesa_ahash_cache_req() function always returns 0, which makes
its return value pretty much useless. However, in addition to
returning a useless value, it also returns a boolean in a variable
passed by reference to indicate if the request was already cached.

So, this commit changes mv_cesa_ahash_cache_req() to return this
boolean. It consequently simplifies the only call site of
mv_cesa_ahash_cache_req(), where the "ret" variable is no longer
needed.

Signed-off-by: Thomas Petazzoni 
Signed-off-by: Herbert Xu

crypto: marvell - turn mv_cesa_ahash_init() into a function returning void

2016-08-09T10:47:29+00:00

The mv_cesa_ahash_init() function always returns 0, and the return
value is anyway never checked. Turn it into a function returning void.

Signed-off-by: Thomas Petazzoni 
Signed-off-by: Herbert Xu

crypto: marvell - remove unused parameter in mv_cesa_ahash_dma_add_cache()

2016-08-09T10:47:29+00:00

The dma_iter parameter of mv_cesa_ahash_dma_add_cache() is never used,
so get rid of it.

Signed-off-by: Thomas Petazzoni 
Signed-off-by: Herbert Xu

crypto: marvell - be explicit about destination in mv_cesa_dma_add_op()

2016-08-09T10:47:29+00:00

The mv_cesa_dma_add_op() function builds a mv_cesa_tdma_desc structure
to copy the operation description to the SRAM, but doesn't explicitly
initialize the destination of the copy. It works fine because the
operatin description must be copied at the beginning of the SRAM, and
the mv_cesa_tdma_desc structure is initialized to zero when
allocated. However, it is somewhat confusing to not have a destination
defined.

Signed-off-by: Thomas Petazzoni 
Signed-off-by: Herbert Xu

crypto: marvell - Don't copy IV vectors from the _process op for ciphers

2016-07-29T10:30:17+00:00

The IV output vectors should only be copied from the _complete operation
and not from the _process operation, i.e only from the operation that is
designed to copy the result of the request to the right location. This
copy is already done in the _complete operation, so this commit removes
the duplicated code in the _process op.

Fixes: 3610d6cd5231 ("crypto: marvell - Add a complete...")
Signed-off-by: Romain Perier 
Acked-by: Boris Brezillon 
Signed-off-by: Herbert Xu