On Wed, Sep 28, 2016 at 08:44:52PM +0800, Herbert Xu wrote:

On Wed, Sep 28, 2016 at 09:38:41AM -0300, Marcelo Cerri wrote:

quoted

The patch forces ghash-generic as the fallback. And I don't think that
is a big problem if we decide to go by this path.

Right it should work but could break for example if we ever decide
to change the exported state structure for ghash and someone unloads
the ghash-generic module and reloads a new one.

Great! If we check the descsize every time a fallback tfm is allocated
that should be enough to prevent bigger problems such as memory
corruptions.

quoted

That would be nice because it would allow p8_ghash to keep using a
dynamic fallback, but I'm not that is viable. What do you think?

We did it for SHA because it was desirable to have multiple
fallbacks, i.e., a generic C version plus an assembly-optimised
version.

Not sure whether the same motiviation exists for GHASH.

quoted

quoted

Otherwise we can go back to allocating just ghash-generic and
also move its data structure into an exported header file.

That would make the fix much more simple and it wouldn't require to get
the fallback descsize at runtime.

This is the easiest fix so let's go with this now.  If we ever
care enough to have multiple fallbacks for GHASH we can always
revisit this.  The exported format is not exposed to user-space
so it can always be changed.

Can I move ghash_desc_ctx to a header file under include/crypto/? Or do
you do you prefer to do that?

Maybe include/crypto/internal/hash.h or a new header file
include/crypto/internal/ghash.h ?

Cheers,
-- 
Email: Herbert Xu [off-list ref]
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt