Received: by 2002:a05:6a10:22f:0:0:0:0 with SMTP id 15csp906083pxk; Fri, 25 Sep 2020 00:32:08 -0700 (PDT) X-Google-Smtp-Source: ABdhPJzdk8cFyFJafSggFJ55WCi23SYS3ZyJdHFqLjuau74jZvJMQ35rodJWpsx4DGF50qdaoA7c X-Received: by 2002:a17:906:22c1:: with SMTP id q1mr1348612eja.529.1601019128702; Fri, 25 Sep 2020 00:32:08 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1601019128; cv=none; d=google.com; s=arc-20160816; b=iamOiYYuau9/Zmup/M5P7mQI6qCmq1a85AZkZc88thqAbMgG3hInZ3H4vXP2Pf4K53 Z9mij3FskM1svKh8ewk6XU8Se/hrs6S386T1Ngq1pfkZxqFANU81ycR1EX55GCOOdPTp 1myRtg7AQ2lp5sDqzfiGh66z+HEX7T4c5GB2t7GkgYfgyxGueBY+P0EwHzH13ahIaj4W EpV2Ubhyt4vCwWKNSmMPGdMceIi81Yr0FI8IBcdmxuaPhS3xjh2tX/+HpgYgh3Pm/25j fmiLGr+NSSfT3ZOhZ1bTpa27Hxu8AGyGDMrF1bTm4zicbY9F92fUoKslsJxKAFj71DPK 9r0g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:user-agent:in-reply-to:content-disposition :mime-version:references:message-id:subject:cc:to:from:date; bh=FNtPwSKSJPS59bvEHbNDXpnMo80Vcj1NsmShxN85IDY=; b=Uk67eRwRdwwbkJqKz81LOirijv9jU2Bg9orQxEnuNEB5Q15zeXpSI6INGv9LdExfxB 5+x7dvU2iHae7yRg7Eymaj1SuiCp9Y5bnouXI2KKGNsWUoh4a/vLPoetJyd+OjsT3t4E 5IX38fN54HWdT5Tkd185mOe5QBwP8OtndO6IcorEsm+J3nfwvz5/u3TM7r1fSVrEOkxv ESXb7jwI9rDOlQXrAhF+3+oNDxFgyhTgxc2iBI/jPqEd9UC487eYM2o+JLk2+ZIlhuRo bsiRRoldQ4ECRdtj7+uSVlvz8XNqk+LdfNG8izpm14yLFfwSqBCdkT4xn6JyEdADY8NJ qxkg== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-crypto-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-crypto-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id e9si1344490edl.154.2020.09.25.00.31.35; Fri, 25 Sep 2020 00:32:08 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-crypto-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-crypto-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-crypto-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727248AbgIYHbd (ORCPT + 99 others); Fri, 25 Sep 2020 03:31:33 -0400 Received: from helcar.hmeau.com ([216.24.177.18]:53000 "EHLO fornost.hmeau.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727238AbgIYHbd (ORCPT ); Fri, 25 Sep 2020 03:31:33 -0400 Received: from gwarestrin.arnor.me.apana.org.au ([192.168.0.7]) by fornost.hmeau.com with smtp (Exim 4.92 #5 (Debian)) id 1kLiBz-0006Ja-MU; Fri, 25 Sep 2020 17:30:56 +1000 Received: by gwarestrin.arnor.me.apana.org.au (sSMTP sendmail emulation); Fri, 25 Sep 2020 17:30:55 +1000 Date: Fri, 25 Sep 2020 17:30:55 +1000 From: Herbert Xu To: Corentin Labbe Cc: arnd@arndb.de, davem@davemloft.net, mripard@kernel.org, wens@csie.org, linux-arm-kernel@lists.infradead.org, linux-crypto@vger.kernel.org, linux-kernel@vger.kernel.org, linux-sunxi@googlegroups.com Subject: Re: [PATCH v2 1/7] crypto: sun4i-ss: linearize buffers content must be kept Message-ID: <20200925073055.GA18879@gondor.apana.org.au> References: <1600627038-40000-1-git-send-email-clabbe@baylibre.com> <1600627038-40000-2-git-send-email-clabbe@baylibre.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1600627038-40000-2-git-send-email-clabbe@baylibre.com> User-Agent: Mutt/1.10.1 (2018-07-13) Precedence: bulk List-ID: X-Mailing-List: linux-crypto@vger.kernel.org On Sun, Sep 20, 2020 at 06:37:12PM +0000, Corentin Labbe wrote: > When running the non-optimized cipher function, SS produce partial random > output. > This is due to linearize buffers being reseted after each loop. > > Fixes: 8d3bcb9900ca ("crypto: sun4i-ss - reduce stack usage") > Signed-off-by: Corentin Labbe > --- > drivers/crypto/allwinner/sun4i-ss/sun4i-ss-cipher.c | 6 ++---- > 1 file changed, 2 insertions(+), 4 deletions(-) > > diff --git a/drivers/crypto/allwinner/sun4i-ss/sun4i-ss-cipher.c b/drivers/crypto/allwinner/sun4i-ss/sun4i-ss-cipher.c > index b72de8939497..b92d175b5d2a 100644 > --- a/drivers/crypto/allwinner/sun4i-ss/sun4i-ss-cipher.c > +++ b/drivers/crypto/allwinner/sun4i-ss/sun4i-ss-cipher.c > @@ -163,6 +163,8 @@ static int sun4i_ss_cipher_poll(struct skcipher_request *areq) > unsigned int todo; > struct sg_mapping_iter mi, mo; > unsigned int oi, oo; /* offset for in and out */ > + char buf[4 * SS_RX_MAX];/* buffer for linearize SG src */ > + char bufo[4 * SS_TX_MAX]; /* buffer for linearize SG dst */ > unsigned int ob = 0; /* offset in buf */ > unsigned int obo = 0; /* offset in bufo*/ > unsigned int obl = 0; /* length of data in bufo */ > @@ -233,8 +235,6 @@ static int sun4i_ss_cipher_poll(struct skcipher_request *areq) > > while (oleft) { > if (ileft) { > - char buf[4 * SS_RX_MAX];/* buffer for linearize SG src */ > - > /* > * todo is the number of consecutive 4byte word that we > * can read from current SG Ouch. So this is obviously correct but I wonder if the stack usage would be an issue again? How about moving this code into another function so that it sits at the same level as the fallback function, which would mean that the buffers do not double up with the one for the fallback? Cheers, -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt