Received: by 2002:ad5:474a:0:0:0:0:0 with SMTP id i10csp2186340imu; Thu, 29 Nov 2018 00:29:44 -0800 (PST) X-Google-Smtp-Source: AFSGD/VWfwIVaqISDaOL4oHr56IrFmlXxcMT6+xK/xfAE79tmT+oQk7Sp545qd2jCtoa9Uv/4yAX X-Received: by 2002:a17:902:1e9:: with SMTP id b96mr564422plb.150.1543480184367; Thu, 29 Nov 2018 00:29:44 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1543480184; cv=none; d=google.com; s=arc-20160816; b=dfocKAG2CwwZ+wq63eQVfyJOUAGaXRoro6H7YesCtzRQ+SH596BU5P56udP+0/v+M5 r3ibbvR5NfwKJRUilTGHVpUjN+OMGHdOXY5/YtRJpM0UcSkccpnVF4OcDK6GqNblbW2x XW1TEr7JCo58ikazqXSmgmb83UgawA29FWFCjmnHwhBB3HvmVdH9UVHq/Co691iGX//e DOALA6e2HCJ+RIRoNSplv6IDimns1n5AHi0A/Dik0enwrIwuPYu6rTCCk9uMmsAGt8Gs 2AxmAZ85UV4Xa6V+kthdBULoJEFKoUgaiiDM8s33EjAxM8kPHD0Hw7KGkwSQLYy8Uqu8 zUjA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date; bh=0x/85mu2iqDxOQIcIHV3S8V1EZLjKI1LaRVQxc54sN0=; b=dfEKdC2dieuJJ6HWpgXDxmJ39Y1Hcf//ModH2/iv5TY4BuqCKVwJs43aAq/emZ2d3w tcnmJFZUuMzbXsxjm+PoW84szfsAmaNeFwkpBCNfuRAumH+tpzOOicBDPYelalHumDgq FIUzFeCCwaZDB5df//lzHbGH/p9Z6FqvZWwCsSwmkpTvYjNCP68LsWMdqmdzhlsi+iCX JDCyyy3snNrDiFgz1G3tBqli6WGUt3EfLefM+G6SztFD/sbmaHoonHpnqtyB70KUgvqf 7ZWX9GRjm+Iy2syleyc5jqcgkkkv0a7IfegMgWxFwp0zbVge5yFvUBcYDp3yQIY+N+Ip pRFQ== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id g17si1180662pgi.578.2018.11.29.00.29.26; Thu, 29 Nov 2018 00:29:44 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727517AbeK2TdX (ORCPT + 99 others); Thu, 29 Nov 2018 14:33:23 -0500 Received: from orcrist.hmeau.com ([104.223.48.154]:53032 "EHLO deadmen.hmeau.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726651AbeK2TdW (ORCPT ); Thu, 29 Nov 2018 14:33:22 -0500 Received: from gondobar.mordor.me.apana.org.au ([192.168.128.4] helo=gondobar) by deadmen.hmeau.com with esmtps (Exim 4.89 #2 (Debian)) id 1gSHgl-0008SO-9o; Thu, 29 Nov 2018 16:28:47 +0800 Received: from herbert by gondobar with local (Exim 4.89) (envelope-from ) id 1gSHgj-00057z-Fs; Thu, 29 Nov 2018 16:28:45 +0800 Date: Thu, 29 Nov 2018 16:28:45 +0800 From: Herbert Xu To: David CARLIER Cc: linux-kernel@vger.kernel.org, "David S. Miller" , linux-crypto@vger.kernel.org Subject: Re: [PATCH] crypto: use memzero_explicit instead of memset to clear contexts. Message-ID: <20181129082845.r3lakg6ckvnkklp7@gondor.apana.org.au> References: <20181129064913.wbudlexjzszpa7dq@gondor.apana.org.au> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: NeoMutt/20170113 (1.7.2) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Nov 29, 2018 at 06:59:50AM +0000, David CARLIER wrote: > Meant regardless how the kernel is compiled (ie optimisation level), > the contexts are guaranteed to be wiped because of the memory fences > used. Please avoid top-posting. > On Thu, 29 Nov 2018 at 06:49, Herbert Xu wrote: > > > > On Wed, Nov 28, 2018 at 07:36:50PM +0000, David CARLIER wrote: > > > There might be a little performance drop but to make sure it stands > > > by it comments, we really wipe the whole context after usage. > > > --- > > > crypto/chacha20poly1305.c | 3 ++- > > > crypto/md5.c | 2 +- > > > crypto/rmd128.c | 3 ++- > > > crypto/rmd160.c | 3 ++- > > > crypto/rmd256.c | 3 ++- > > > crypto/rmd320.c | 3 ++- > > > crypto/sha3_generic.c | 3 ++- > > > 7 files changed, 13 insertions(+), 7 deletions(-) > > > > > > diff --git a/crypto/chacha20poly1305.c b/crypto/chacha20poly1305.c > > > index 600afa99941f..6e93d998109e 100644 > > > --- a/crypto/chacha20poly1305.c > > > +++ b/crypto/chacha20poly1305.c > > > @@ -19,6 +19,7 @@ > > > #include > > > #include > > > #include > > > +#include > > > > > > #include "internal.h" > > > > > > @@ -388,7 +389,7 @@ static int poly_genkey(struct aead_request *req) > > > } > > > > > > sg_init_table(creq->src, 1); > > > - memset(rctx->key, 0, sizeof(rctx->key)); > > > + memzero_explicit(rctx->key, sizeof(rctx->key)); > > > > Please explain the purpose of this patch. As it stands this > > makes no sense. memzero_explicit is really only useful for stack memory. You need to explain why it makes sense to use it in this context. For example, by providing an example of a miscompile or how it is even possible for this to happen. Thanks, -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt