mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Giel van Schijndel <me@mortis.eu>
To: Herbert Xu <herbert@gondor.apana.org.au>
Cc: linux-kernel@vger.kernel.org,
	"David S. Miller" <davem@davemloft.net>,
	Thomas Gleixner <tglx@linutronix.de>,
	Ingo Molnar <mingo@redhat.com>, "H. Peter Anvin" <hpa@zytor.com>,
	"maintainer:X86 ARCHITECTURE..." <x86@kernel.org>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	Steve French <sfrench@samba.org>,
	Rahul Bedarkar <rahulbedarkar89@gmail.com>,
	Thomas Pugliese <thomas.pugliese@gmail.com>,
	Randy Dunlap <rdunlap@infradead.org>,
	Julia Lawall <Julia.Lawall@lip6.fr>,
	"open list:CRYPTO API" <linux-crypto@vger.kernel.org>,
	"open list:CERTIFIED WIRELES..." <linux-usb@vger.kernel.org>,
	"open list:COMMON INTERNET F..." <linux-cifs@vger.kernel.org>,
	"moderated list:COMMON INTERNET F..." 
	<samba-technical@lists.samba.org>
Subject: Re: [PATCH] Use memzero_explicit to clear local buffers
Date: Sun, 4 Jan 2015 23:49:09 +0100	[thread overview]
Message-ID: <20150104224909.GB4806@salidar.dom.custoft.eu> (raw)
In-Reply-To: <20150104213538.GA19906@gondor.apana.org.au>

[-- Attachment #1: Type: text/plain, Size: 2133 bytes --]

On Mon, Jan 05, 2015 at 08:35:38 +1100, Herbert Xu wrote:
> On Sun, Jan 04, 2015 at 07:05:40PM +0100, Giel van Schijndel wrote:
>> When leaving a function use memzero_explicit instead of memset(0) to
>> clear locally allocated/owned buffers. memset(0) may be optimized away.
>> 
>> All of the affected buffers contain sensitive data, key material or
>> derivatives of one of those two.
> 
> Nack.

Do you mean that the sample below doesn't contain sensitive data?
Or is there another buffer(s) in my patch that you believe doesn't
contain that?

(I contain a hash derived from secret material to be a "derivative of one of
those two", leaking of which could lead to a confirmation-attack).

>> diff --git a/arch/x86/crypto/sha256_ssse3_glue.c b/arch/x86/crypto/sha256_ssse3_glue.c
>> index 8fad72f..b616e63 100644
>> --- a/arch/x86/crypto/sha256_ssse3_glue.c
>> +++ b/arch/x86/crypto/sha256_ssse3_glue.c
>> @@ -164,7 +164,7 @@ static int sha256_ssse3_final(struct shash_desc *desc, u8 *out)
>>  		dst[i] = cpu_to_be32(sctx->state[i]);
>>  
>>  	/* Wipe context */
>> -	memset(sctx, 0, sizeof(*sctx));
>> +	memzero_explicit(sctx, sizeof(*sctx));
> 
> sctx does not point to stack memory so this is bogus.
> 
> Only stack memory cleared just before it goes out of scope needs
> memzero_explicit.

Is that because the compiler can't safely optimize memset(0) away for a
variable with greater-than-local scope?

Because I think using memzero_explicit() as an indicator that said
buffer contains data that really *needs* to be destroyed is enough of a
reason already. I believe any overhead is negligable because there's
only a single extra call involved and that's cheap for the extra clarity
it buys (i.e. "this piece of memory *really* needs to be destroyed
beyond this statement"). (Though this approach is only valid for memory
that can contain security-sensitive data IMO.)

-- 
Met vriendelijke groet,
With kind regards,
Giel van Schijndel
--
"Always code as if the guy who ends up maintaining your code will be a
 violent psychopath who knows where you live."
  -- Rick Osborne

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]

  reply	other threads:[~2015-01-04 22:49 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-01-04 18:05 Giel van Schijndel
2015-01-04 21:35 ` Herbert Xu
2015-01-04 22:49   ` Giel van Schijndel [this message]
2015-01-04 23:36     ` Herbert Xu
2015-01-06 19:42       ` Giel van Schijndel
2015-01-06 20:54         ` Herbert Xu
2015-01-04 23:05 ` Giel van Schijndel
2015-01-06 21:37 ` [PATCH RESEND] cifs: use memzero_explicit to clear stack buffer Giel van Schijndel
2015-01-06 22:59   ` Herbert Xu
2015-01-13  0:12     ` Steve French
2015-01-09 18:53   ` Steve French

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20150104224909.GB4806@salidar.dom.custoft.eu \
    --to=me@mortis.eu \
    --cc=Julia.Lawall@lip6.fr \
    --cc=davem@davemloft.net \
    --cc=gregkh@linuxfoundation.org \
    --cc=herbert@gondor.apana.org.au \
    --cc=hpa@zytor.com \
    --cc=linux-cifs@vger.kernel.org \
    --cc=linux-crypto@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-usb@vger.kernel.org \
    --cc=mingo@redhat.com \
    --cc=rahulbedarkar89@gmail.com \
    --cc=rdunlap@infradead.org \
    --cc=samba-technical@lists.samba.org \
    --cc=sfrench@samba.org \
    --cc=tglx@linutronix.de \
    --cc=thomas.pugliese@gmail.com \
    --cc=x86@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®