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: > > > > 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. > > 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. > > > > 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 <herbert@xxxxxxxxxxxxxxxxxxx> > Home Page: http://gondor.apana.org.au/~herbert/ > PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Attachment:
signature.asc
Description: PGP signature
