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 --]
next prev parent 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®