[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20160928124452.GA21011@gondor.apana.org.au>
Date: Wed, 28 Sep 2016 20:44:52 +0800
From: Herbert Xu <herbert@...dor.apana.org.au>
To: Marcelo Cerri <marcelo.cerri@...onical.com>
Cc: Jan Stancek <jstancek@...hat.com>,
rui y wang <rui.y.wang@...el.com>,
mhcerri@...ux.vnet.ibm.com, leosilva@...ux.vnet.ibm.com,
pfsmorigo@...ux.vnet.ibm.com, linux-crypto@...r.kernel.org,
linuxppc-dev@...ts.ozlabs.org, linux-kernel@...r.kernel.org
Subject: Re: [bug] crypto/vmx/p8_ghash memory corruption in 4.8-rc7
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.
> 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.
Cheers,
--
Email: Herbert Xu <herbert@...dor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Powered by blists - more mailing lists