Thread (21 messages) 21 messages, 4 authors, 2016-09-28

Re: [bug] crypto/vmx/p8_ghash memory corruption in 4.8-rc7

From: Herbert Xu <herbert@gondor.apana.org.au>
Date: 2016-09-28 12:33:56
Also in: linux-crypto, lkml

On Wed, Sep 28, 2016 at 09:28:44AM -0300, Marcelo Cerri wrote:
The big difference between p8_ghash and padlock_sha1 is that
padlock_sha1 defines alg->statesize as sizeof(struct sha1_state), which
is the descsize value used by sha1_generic. This probably works but
it's also wrong because the padlock_sha1 driver does not ensures that
sha1_generic is always used.
It should work because all our SHA implementations use the same
export format.  This is not necessarily the case for GHASH though.
So, one solution is to hardcode ghash-generic as the fallback algorithm
and update the descsize direct in its shash_alg structure. There's only
one problem with that. ghash-generic desc type (struct ghash_desc_ctx)
is not available for vmx_crypto at compile type, the type is defined
directly in crypto/ghash-generic.c. That's the reason I added a function
to get the fallback desc size at runtime in the patch I wrote as a prove
of concept.
The problem with your patch is that there is no guarantee that
you will get the same algorithm every time you allocate a fallback.
Someone may have loaded a new module for example.

So I think the safe approach is to stick with ghash-generic and
expose its state data structure in a header file.

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