linux-kernel - Re: [PATCH] Use memzero_explicit to clear local buffers

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: <20150104224909.GB4806@salidar.dom.custoft.eu>
Date:	Sun, 4 Jan 2015 23:49:09 +0100
From:	Giel van Schijndel <me@...tis.eu>
To:	Herbert Xu <herbert@...dor.apana.org.au>
Cc:	linux-kernel@...r.kernel.org,
	"David S. Miller" <davem@...emloft.net>,
	Thomas Gleixner <tglx@...utronix.de>,
	Ingo Molnar <mingo@...hat.com>,
	"H. Peter Anvin" <hpa@...or.com>,
	"maintainer:X86 ARCHITECTURE..." <x86@...nel.org>,
	Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
	Steve French <sfrench@...ba.org>,
	Rahul Bedarkar <rahulbedarkar89@...il.com>,
	Thomas Pugliese <thomas.pugliese@...il.com>,
	Randy Dunlap <rdunlap@...radead.org>,
	Julia Lawall <Julia.Lawall@...6.fr>,
	"open list:CRYPTO API" <linux-crypto@...r.kernel.org>,
	"open list:CERTIFIED WIRELES..." <linux-usb@...r.kernel.org>,
	"open list:COMMON INTERNET F..." <linux-cifs@...r.kernel.org>,
	"moderated list:COMMON INTERNET F..." 
	<samba-technical@...ts.samba.org>
Subject: Re: [PATCH] Use memzero_explicit to clear local buffers

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

Download attachment "signature.asc" of type "application/pgp-signature" (182 bytes)