Thread (10 messages) 10 messages, 2 authors, 2015-11-19

Re: [PATCH v2 1/5] crypto: Multi-buffer encryptioin infrastructure support

From: Herbert Xu <herbert@gondor.apana.org.au>
Date: 2015-11-19 09:40:13
Also in: lkml

On Wed, Nov 18, 2015 at 06:39:30PM -0800, Tim Chen wrote:
The __cbc-aes-aesni-mb algorithm is marked as internal algorithm 
with flag CRYPTO_ALG_INTERNAL, so it should not be picked up by other
algorithms and should only be invoked from mcryptd.
OK I guess that's fine then.
Anyway, I've udpated the aes_cbc_mb code with ablkcipher helper.
So I will be posting the new series with ablkcipher walk
after testing is done.
Yes I think what you have is a very special case.  As you said
the ablkcipher interface should be fairly low in overhead so I
think it makes sense to use that instead of blkcipher.
The __sha1-mb works in tandem with the outer layer of mcryptd 
aysnc algorithm. It does the completion for the outer 
async algorithm.  So as far as mcryptd is concerned, the
inner algorithm is synchronous in the sense that it is done
once it dispatch the job to __sha1-mb and don't have to worry about it.
I don't think mcryptd check for the return value from __sha1-mb
so it should be okay to return 0 instead of -EINPROGRESS.  
I'll double check that.
If it can never return EINPROGRESS then we should probably remove
the code in it that says "return -EINPROGRESS".

Thanks,
-- 
Email: Herbert Xu [off-list ref]
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help