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=unavailable 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 0065CC2BB1D for ; Tue, 14 Apr 2020 19:34:53 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id DCA9E206E9 for ; Tue, 14 Apr 2020 19:34:52 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2504894AbgDNTet (ORCPT ); Tue, 14 Apr 2020 15:34:49 -0400 Received: from mx2.suse.de ([195.135.220.15]:60298 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S2504805AbgDNTdv (ORCPT ); Tue, 14 Apr 2020 15:33:51 -0400 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 Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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 à 00:28, Waiman Long a écrit : > >> Since kfree_sensitive() will do an implicit memzero_explicit(), there > >> is no need to call memzero_explicit() before it. Eliminate those > >> memzero_explicit() and simplify the call sites. For better correctness, > >> the setting of keylen is also moved down after the key pointer check. > >> > >> Signed-off-by: Waiman Long > >> --- > >>   .../allwinner/sun8i-ce/sun8i-ce-cipher.c      | 19 +++++------------- > >>   .../allwinner/sun8i-ss/sun8i-ss-cipher.c      | 20 +++++-------------- > >>   drivers/crypto/amlogic/amlogic-gxl-cipher.c   | 12 +++-------- > >>   drivers/crypto/inside-secure/safexcel_hash.c  |  3 +-- > >>   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 *tfm) > >>   { > >>       struct sun8i_cipher_tfm_ctx *op = crypto_tfm_ctx(tfm); > >>   -    if (op->key) { > >> -        memzero_explicit(op->key, op->keylen); > >> -        kfree(op->key); > >> -    } > >> +    kfree_sensitive(op->key); > >>       crypto_free_sync_skcipher(op->fallback_tfm); > >>       pm_runtime_put_sync_suspend(op->ce->dev); > >>   } > >> @@ -391,14 +388,11 @@ int sun8i_ce_aes_setkey(struct crypto_skcipher > >> *tfm, const u8 *key, > >>           dev_dbg(ce->dev, "ERROR: Invalid keylen %u\n", keylen); > >>           return -EINVAL; > >>       } > >> -    if (op->key) { > >> -        memzero_explicit(op->key, op->keylen); > >> -        kfree(op->key); > >> -    } > >> -    op->keylen = keylen; > >> +    kfree_sensitive(op->key); > >>       op->key = kmemdup(key, keylen, GFP_KERNEL | GFP_DMA); > >>       if (!op->key) > >>           return -ENOMEM; > >> +    op->keylen = 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->key. > > 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