On Tue, Feb 02, 2016 at 03:18:47PM -0200, Fabio Estevam wrote:
> On Tue, Feb 2, 2016 at 12:43 PM, Herbert Xu
> wrote:
>
> > Preferably you shouldn't include the mutex in the exported state
> > at all.
>
> Ok, so would it be safe to completely remove the mutex like this?
Hmm, indeed the mutex s
On Tue, Feb 2, 2016 at 12:43 PM, Herbert Xu wrote:
> Preferably you shouldn't include the mutex in the exported state
> at all.
Ok, so would it be safe to completely remove the mutex like this?
--- a/drivers/crypto/sahara.c
+++ b/drivers/crypto/sahara.c
@@ -182,7 +182,6 @@ struct sahara_sha_req
On Tue, Feb 02, 2016 at 11:41:56AM -0200, Fabio Estevam wrote:
>
> static int sahara_sha_import(struct ahash_request *req, const void *in)
> {
> struct sahara_sha_reqctx *rctx = ahash_request_ctx(req);
>
> mutex_init(&rctx->mutex);
> memcpy(rctx, in, sizeof(struct sahara_sha_reqctx));
Hi Herbert,
On Mon, Jan 25, 2016 at 12:07 PM, Herbert Xu
wrote:
> Very good. Not only is it a waste, it's a gaping security hole
> because modifying the tfm from import will corrupt it.
>
> But this is not enough, you're still copying things like the mutex
> which should not be copied but inste
On Wed, Jan 13, 2016 at 03:52:02PM -0200, Fabio Estevam wrote:
> From: Fabio Estevam
>
> Based on commit 434b421241f2d0 ("crypto: caam - avoid needlessly saving and
> restoring caam_hash_ctx") from Russell King.
>
> When exporting and importing the hash state, we will only export and
> import in
