From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932601AbcI1NXQ (ORCPT ); Wed, 28 Sep 2016 09:23:16 -0400 Received: from mx0a-001b2d01.pphosted.com ([148.163.156.1]:38006 "EHLO mx0a-001b2d01.pphosted.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932302AbcI1NXI (ORCPT ); Wed, 28 Sep 2016 09:23:08 -0400 Date: Wed, 28 Sep 2016 10:22:51 -0300 From: Paulo Flabiano Smorigo To: Herbert Xu Cc: Marcelo Cerri , Jan Stancek , rui y wang , mhcerri@linux.vnet.ibm.com, leosilva@linux.vnet.ibm.com, linux-crypto@vger.kernel.org, linuxppc-dev@lists.ozlabs.org, linux-kernel@vger.kernel.org Subject: Re: [bug] crypto/vmx/p8_ghash memory corruption in 4.8-rc7 References: <1655600242.1561022.1474676547316.JavaMail.zimbra@redhat.com> <20160926145934.GA5520@gondor.apana.org.au> <20160926174317.GA21317@gallifrey> <20160927030826.GB8579@gondor.apana.org.au> <346154437.225735.1474966863173.JavaMail.zimbra@redhat.com> <20160927120414.GC21317@gallifrey> <20160927194644.GB15729@gallifrey> <20160928024549.GB14034@gondor.apana.org.au> <20160928122844.GC15729@gallifrey> <20160928123318.GB20839@gondor.apana.org.au> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20160928123318.GB20839@gondor.apana.org.au> User-Agent: Mutt/1.7.0 (2016-08-17) X-TM-AS-MML: disable X-Content-Scanned: Fidelis XPS MAILER x-cbid: 16092813-0024-0000-0000-0000010EF1B2 X-IBM-AV-DETECTION: SAVI=unused REMOTE=unused XFE=unused x-cbparentid: 16092813-0025-0000-0000-000015C0CE58 Message-Id: <20160928132251.GB5010@dublin> X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:,, definitions=2016-09-28_08:,, signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1609020000 definitions=main-1609280235 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Wed, Sep 28, 2016 at 08:33:18PM +0800, Herbert Xu wrote: > 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. Since generic is the only posible fallback for ppc, I think that's a good solution. :) > > Thanks, > -- > Email: Herbert Xu > Home Page: http://gondor.apana.org.au/~herbert/ > PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt > -- Paulo Flabiano Smorigo IBM Linux Technology Center