netdev - Re: [PATCH v4 1/3] mm/slab: Use 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: <20200616033035.GB902@sol.localdomain>
Date:   Mon, 15 Jun 2020 20:30:35 -0700
From:   Eric Biggers <ebiggers@...nel.org>
To:     Waiman Long <longman@...hat.com>
Cc:     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>,
        Michal Hocko <mhocko@...e.com>,
        Johannes Weiner <hannes@...xchg.org>,
        Dan Carpenter <dan.carpenter@...cle.com>,
        David Sterba <dsterba@...e.cz>,
        "Jason A . Donenfeld" <Jason@...c4.com>, linux-mm@...ck.org,
        keyrings@...r.kernel.org, linux-kernel@...r.kernel.org,
        linux-crypto@...r.kernel.org, linux-pm@...r.kernel.org,
        linux-stm32@...md-mailman.stormreply.com,
        linux-amlogic@...ts.infradead.org,
        linux-mediatek@...ts.infradead.org, linuxppc-dev@...ts.ozlabs.org,
        virtualization@...ts.linux-foundation.org, netdev@...r.kernel.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,
        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,
        linux-security-module@...r.kernel.org,
        linux-integrity@...r.kernel.org, stable@...r.kernel.org
Subject: Re: [PATCH v4 1/3] mm/slab: Use memzero_explicit() in kzfree()

On Mon, Jun 15, 2020 at 09:57:16PM -0400, Waiman Long wrote:
> The kzfree() function is normally used to clear some sensitive
> information, like encryption keys, in the buffer before freeing it back
> to the pool. Memset() is currently used for the buffer clearing. However,
> it is entirely possible that the compiler may choose to optimize away the
> memory clearing especially if LTO is being used. To make sure that this
> optimization will not happen, memzero_explicit(), which is introduced
> in v3.18, is now used in kzfree() to do the clearing.
> 
> Fixes: 3ef0e5ba4673 ("slab: introduce kzfree()")
> Cc: stable@...r.kernel.org
> Signed-off-by: Waiman Long <longman@...hat.com>
> ---
>  mm/slab_common.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/mm/slab_common.c b/mm/slab_common.c
> index 9e72ba224175..37d48a56431d 100644
> --- a/mm/slab_common.c
> +++ b/mm/slab_common.c
> @@ -1726,7 +1726,7 @@ void kzfree(const void *p)
>  	if (unlikely(ZERO_OR_NULL_PTR(mem)))
>  		return;
>  	ks = ksize(mem);
> -	memset(mem, 0, ks);
> +	memzero_explicit(mem, ks);
>  	kfree(mem);
>  }
>  EXPORT_SYMBOL(kzfree);

This is a good change, but the commit message isn't really accurate.  AFAIK, no
one has found any case where this memset() gets optimized out.  And even with
LTO, it would be virtually impossible due to all the synchronization and global
data structures that kfree() uses.  (Remember that this isn't the C standard
function "free()", so the compiler can't assign it any special meaning.)
Not to mention that LTO support isn't actually upstream yet.

I still agree with the change, but it might be helpful if the commit message
were honest that this is really a hardening measure and about properly conveying
the intent.  As-is this sounds like a critical fix, which might confuse people.

- Eric