From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-8.3 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, INCLUDES_PATCH,MAILING_LIST_MULTI,SIGNED_OFF_BY,SPF_HELO_NONE,SPF_PASS, USER_AGENT_SANE_1 autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 17240C2BA19 for ; Tue, 14 Apr 2020 19:16:11 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id CE37B2078A for ; Tue, 14 Apr 2020 19:16:10 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org CE37B2078A Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=suse.de Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 76AA38E000A; Tue, 14 Apr 2020 15:16:10 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 6F3738E0001; Tue, 14 Apr 2020 15:16:10 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 5E2B28E000A; Tue, 14 Apr 2020 15:16:10 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0149.hostedemail.com [216.40.44.149]) by kanga.kvack.org (Postfix) with ESMTP id 434DE8E0001 for ; Tue, 14 Apr 2020 15:16:10 -0400 (EDT) Received: from smtpin04.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay04.hostedemail.com (Postfix) with ESMTP id 0AB6F2C1F for ; Tue, 14 Apr 2020 19:16:10 +0000 (UTC) X-FDA: 76707416100.04.touch59_6ffa5bfdae752 X-HE-Tag: touch59_6ffa5bfdae752 X-Filterd-Recvd-Size: 5555 Received: from mx2.suse.de (mx2.suse.de [195.135.220.15]) by imf42.hostedemail.com (Postfix) with ESMTP for ; Tue, 14 Apr 2020 19:16:09 +0000 (UTC) X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.220.254]) by mx2.suse.de (Postfix) with ESMTP id 63506AC2C; Tue, 14 Apr 2020 19:16:04 +0000 (UTC) Date: Tue, 14 Apr 2020 21:16:01 +0200 From: Michal =?iso-8859-1?Q?Such=E1nek?= To: Waiman Long Cc: Christophe Leroy , Andrew Morton , David Howells , Jarkko Sakkinen , James Morris , "Serge E. Hallyn" , Linus Torvalds , Joe Perches , Matthew Wilcox , David Rientjes , linux-mm@kvack.org, keyrings@vger.kernel.org, linux-kernel@vger.kernel.org, x86@kernel.org, linux-crypto@vger.kernel.org, linux-s390@vger.kernel.org, linux-pm@vger.kernel.org, linux-stm32@st-md-mailman.stormreply.com, linux-arm-kernel@lists.infradead.org, linux-amlogic@lists.infradead.org, linux-mediatek@lists.infradead.org, linuxppc-dev@lists.ozlabs.org, virtualization@lists.linux-foundation.org, netdev@vger.kernel.org, intel-wired-lan@lists.osuosl.org, linux-ppp@vger.kernel.org, wireguard@lists.zx2c4.com, linux-wireless@vger.kernel.org, devel@driverdev.osuosl.org, linux-scsi@vger.kernel.org, target-devel@vger.kernel.org, linux-btrfs@vger.kernel.org, linux-cifs@vger.kernel.org, samba-technical@lists.samba.org, linux-fscrypt@vger.kernel.org, ecryptfs@vger.kernel.org, kasan-dev@googlegroups.com, linux-bluetooth@vger.kernel.org, linux-wpan@vger.kernel.org, linux-sctp@vger.kernel.org, linux-nfs@vger.kernel.org, tipc-discussion@lists.sourceforge.net, cocci@systeme.lip6.fr, linux-security-module@vger.kernel.org, linux-integrity@vger.kernel.org Subject: Re: [PATCH v2 2/2] crypto: Remove unnecessary memzero_explicit() Message-ID: <20200414191601.GZ25468@kitsune.suse.cz> References: <20200413211550.8307-1-longman@redhat.com> <20200413222846.24240-1-longman@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) Content-Transfer-Encoding: quoted-printable X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Tue, Apr 14, 2020 at 12:24:36PM -0400, Waiman Long wrote: > On 4/14/20 2:08 AM, Christophe Leroy wrote: > > > > > > Le 14/04/2020 =E0 00:28, Waiman Long a =E9crit=A0: > >> Since kfree_sensitive() will do an implicit memzero_explicit(), ther= e > >> is no need to call memzero_explicit() before it. Eliminate those > >> memzero_explicit() and simplify the call sites. For better correctne= ss, > >> the setting of keylen is also moved down after the key pointer check= . > >> > >> Signed-off-by: Waiman Long > >> --- > >> =A0 .../allwinner/sun8i-ce/sun8i-ce-cipher.c=A0=A0=A0=A0=A0 | 19 +++= ++------------- > >> =A0 .../allwinner/sun8i-ss/sun8i-ss-cipher.c=A0=A0=A0=A0=A0 | 20 +++= ++-------------- > >> =A0 drivers/crypto/amlogic/amlogic-gxl-cipher.c=A0=A0 | 12 +++------= -- > >> =A0 drivers/crypto/inside-secure/safexcel_hash.c=A0 |=A0 3 +-- > >> =A0 4 files changed, 14 insertions(+), 40 deletions(-) > >> > >> diff --git a/drivers/crypto/allwinner/sun8i-ce/sun8i-ce-cipher.c > >> b/drivers/crypto/allwinner/sun8i-ce/sun8i-ce-cipher.c > >> index aa4e8fdc2b32..8358fac98719 100644 > >> --- a/drivers/crypto/allwinner/sun8i-ce/sun8i-ce-cipher.c > >> +++ b/drivers/crypto/allwinner/sun8i-ce/sun8i-ce-cipher.c > >> @@ -366,10 +366,7 @@ void sun8i_ce_cipher_exit(struct crypto_tfm *tf= m) > >> =A0 { > >> =A0=A0=A0=A0=A0 struct sun8i_cipher_tfm_ctx *op =3D crypto_tfm_ctx(t= fm); > >> =A0 -=A0=A0=A0 if (op->key) { > >> -=A0=A0=A0=A0=A0=A0=A0 memzero_explicit(op->key, op->keylen); > >> -=A0=A0=A0=A0=A0=A0=A0 kfree(op->key); > >> -=A0=A0=A0 } > >> +=A0=A0=A0 kfree_sensitive(op->key); > >> =A0=A0=A0=A0=A0 crypto_free_sync_skcipher(op->fallback_tfm); > >> =A0=A0=A0=A0=A0 pm_runtime_put_sync_suspend(op->ce->dev); > >> =A0 } > >> @@ -391,14 +388,11 @@ int sun8i_ce_aes_setkey(struct crypto_skcipher > >> *tfm, const u8 *key, > >> =A0=A0=A0=A0=A0=A0=A0=A0=A0 dev_dbg(ce->dev, "ERROR: Invalid keylen = %u\n", keylen); > >> =A0=A0=A0=A0=A0=A0=A0=A0=A0 return -EINVAL; > >> =A0=A0=A0=A0=A0 } > >> -=A0=A0=A0 if (op->key) { > >> -=A0=A0=A0=A0=A0=A0=A0 memzero_explicit(op->key, op->keylen); > >> -=A0=A0=A0=A0=A0=A0=A0 kfree(op->key); > >> -=A0=A0=A0 } > >> -=A0=A0=A0 op->keylen =3D keylen; > >> +=A0=A0=A0 kfree_sensitive(op->key); > >> =A0=A0=A0=A0=A0 op->key =3D kmemdup(key, keylen, GFP_KERNEL | GFP_DM= A); > >> =A0=A0=A0=A0=A0 if (!op->key) > >> =A0=A0=A0=A0=A0=A0=A0=A0=A0 return -ENOMEM; > >> +=A0=A0=A0 op->keylen =3D keylen; > > > > Does it matter at all to ensure op->keylen is not set when of->key is > > NULL ? I'm not sure. > > > > But if it does, then op->keylen should be set to 0 when freeing op->k= ey.=20 >=20 > My thinking is that if memory allocation fails, we just don't touch > anything and return an error code. I will not explicitly set keylen to = 0 > in this case unless it is specified in the API documentation. You already freed the key by now so not touching anything is not possible. The key is set to NULL on allocation failure so setting keylen to 0 should be redundant. However, setting keylen to 0 is consisent with not having a key, and it avoids the possibility of leaking the length later should that ever cause any problem. Thanks Michal