----- Original Message -----

From: "Herbert Xu" <herbert@gondor.apana.org.au>
To: "Marcelo Cerri" <redacted>
Cc: "Jan Stancek" <jstancek@redhat.com>, "rui y wang" <redacted>, mhcerri@linux.vnet.ibm.com,
leosilva@linux.vnet.ibm.com, pfsmorigo@linux.vnet.ibm.com, linux-crypto@vger.kernel.org,
linuxppc-dev@lists.ozlabs.org, linux-kernel@vger.kernel.org
Sent: Tuesday, 27 September, 2016 5:08:26 AM
Subject: Re: [bug] crypto/vmx/p8_ghash memory corruption in 4.8-rc7

On Mon, Sep 26, 2016 at 02:43:17PM -0300, Marcelo Cerri wrote:

quoted

Wouldn't be enough to provide a pair of import/export functions as the
padlock-sha driver does?

I don't think that will help as ultimately you need to call the
export function on the fallback and that's what requires the extra
memory.  In fact very operation involving the fallback will need
that extra memory too.

So, if we extended p8_ghash_desc_ctx to accommodate fallback_desc's ctx
and then provided statesize/import/export, would that be acceptable?

struct p8_ghash_desc_ctx {
        ...
        struct shash_desc fallback_desc;
+       char fallback_ctx[sizeof(struct ghash_desc_ctx)];


Also, does that mean that padlock_sha has similar problem?
It does not seem to reserve any space for fallback __ctx and it calls
init()/update()/export() with padlock_sha_desc's fallback:

struct padlock_sha_desc {
        struct shash_desc fallback;
};

static struct shash_alg sha1_alg = {
        .descsize       =       sizeof(struct padlock_sha_desc),

Regards,
Jan

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