From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753256AbbHNGP3 (ORCPT ); Fri, 14 Aug 2015 02:15:29 -0400 Received: from mga01.intel.com ([192.55.52.88]:5601 "EHLO mga01.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752152AbbHNGP2 (ORCPT ); Fri, 14 Aug 2015 02:15:28 -0400 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.15,675,1432623600"; d="scan'208";a="783931962" Message-ID: <55CD8733.2000904@intel.com> Date: Thu, 13 Aug 2015 23:14:11 -0700 From: Tadeusz Struk User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Herbert Xu CC: keescook@chromium.org, jwboyer@redhat.com, smueller@chronox.de, richard@nod.at, steved@redhat.com, linux-kernel@vger.kernel.org, dhowells@redhat.com, linux-crypto@vger.kernel.org, james.l.morris@oracle.com, jkosina@suse.cz, zohar@linux.vnet.ibm.com, davem@davemloft.net, vgoyal@redhat.com Subject: Re: [PATCH 2/2] crypto: qat - Don't move data inside output buffer References: <20150813035433.25108.3065.stgit@tstruk-mobl1> <20150813035445.25108.76927.stgit@tstruk-mobl1> <20150814051410.GA2370@gondor.apana.org.au> In-Reply-To: <20150814051410.GA2370@gondor.apana.org.au> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 08/13/2015 10:14 PM, Herbert Xu wrote: >> diff --git a/drivers/crypto/qat/qat_common/qat_asym_algs.c b/drivers/crypto/qat/qat_common/qat_asym_algs.c >> > index fe352a6..6ddb13c 100644 >> > --- a/drivers/crypto/qat/qat_common/qat_asym_algs.c >> > +++ b/drivers/crypto/qat/qat_common/qat_asym_algs.c >> > @@ -144,9 +144,6 @@ static void qat_rsa_cb(struct icp_qat_fw_pke_resp *resp) >> > ptr++; >> > } >> > >> > - if (areq->dst_len != req->ctx->key_sz) >> > - memcpy(areq->dst, ptr, areq->dst_len); >> > - > This looks wrong. It appears to be trying to remove leading > zeroes so you can't just change the length because then you end > up removing the trailing digits equal to the number of leading > zeroes. What it does is it sets the size of the output number, not the size of the output buffer. The size of the buffer is set beforehand to the size of the modulo, which is the biggest possible output. > > The existing code is also wrong as you should be using memmove > instead of memcpy. Right, but we don't need that anymore.