netdev - Re: [PATCH v2 2/2] crypto: Remove unnecessary memzero

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20200414191601.GZ25468@kitsune.suse.cz>
Date:   Tue, 14 Apr 2020 21:16:01 +0200
From:   Michal Suchánek <msuchanek@...e.de>
To:     Waiman Long <longman@...hat.com>
Cc:     Christophe Leroy <christophe.leroy@....fr>,
        Andrew Morton <akpm@...ux-foundation.org>,
        David Howells <dhowells@...hat.com>,
        Jarkko Sakkinen <jarkko.sakkinen@...ux.intel.com>,
        James Morris <jmorris@...ei.org>,
        "Serge E. Hallyn" <serge@...lyn.com>,
        Linus Torvalds <torvalds@...ux-foundation.org>,
        Joe Perches <joe@...ches.com>,
        Matthew Wilcox <willy@...radead.org>,
        David Rientjes <rientjes@...gle.com>, linux-mm@...ck.org,
        keyrings@...r.kernel.org, linux-kernel@...r.kernel.org,
        x86@...nel.org, linux-crypto@...r.kernel.org,
        linux-s390@...r.kernel.org, linux-pm@...r.kernel.org,
        linux-stm32@...md-mailman.stormreply.com,
        linux-arm-kernel@...ts.infradead.org,
        linux-amlogic@...ts.infradead.org,
        linux-mediatek@...ts.infradead.org, linuxppc-dev@...ts.ozlabs.org,
        virtualization@...ts.linux-foundation.org, netdev@...r.kernel.org,
        intel-wired-lan@...ts.osuosl.org, linux-ppp@...r.kernel.org,
        wireguard@...ts.zx2c4.com, linux-wireless@...r.kernel.org,
        devel@...verdev.osuosl.org, linux-scsi@...r.kernel.org,
        target-devel@...r.kernel.org, linux-btrfs@...r.kernel.org,
        linux-cifs@...r.kernel.org, samba-technical@...ts.samba.org,
        linux-fscrypt@...r.kernel.org, ecryptfs@...r.kernel.org,
        kasan-dev@...glegroups.com, linux-bluetooth@...r.kernel.org,
        linux-wpan@...r.kernel.org, linux-sctp@...r.kernel.org,
        linux-nfs@...r.kernel.org, tipc-discussion@...ts.sourceforge.net,
        cocci@...teme.lip6.fr, linux-security-module@...r.kernel.org,
        linux-integrity@...r.kernel.org
Subject: Re: [PATCH v2 2/2] crypto: Remove unnecessary memzero_explicit()

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 <longman@...hat.com>
> >> ---
> >>   .../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