From: Andi Kleen <andi@firstfloor.org>
To: Roel Kluin <roel.kluin@gmail.com>
Cc: "David S. Miller" <davem@davemloft.net>,
Mikael Pettersson <mikpe@it.uu.se>,
penberg@cs.helsinki.fi, Brian Gerst <brgerst@gmail.com>,
andi@firstfloor.org, Andrew Morton <akpm@linux-foundation.org>,
LKML <linux-kernel@vger.kernel.org>,
linux-crypto@vger.kernel.org, Herbert@gondor.apana.org.au
Subject: Re: [PATCH v1] compiler: prevent dead store elimination
Date: Sun, 28 Feb 2010 10:55:20 +0100 [thread overview]
Message-ID: <20100228095520.GA29531@one.firstfloor.org> (raw)
In-Reply-To: <4B8984EE.8090605@gmail.com>
> Every byte in the [p,p+n[ range must be used. If you only use the
> first byte, via e.g. asm("" :: "m"(*(char*)p)), then the compiler
> _will_ skip scrubbing bytes beyond the first. This works with
> gcc-3.2.3 up to gcc-4.4.3.
You forgot to credit Mikael who did all the hard work figuring
this out?
> /*
> + * Dead store elimination (DSE) is an optimization that may remove a write to
> + * a buffer that is not used anymore. Use ARRAY_PREVENT_DSE after a write when
> + * the scrub is required for security reasons.
> + */
> +#define ARRAY_PREVENT_DSE(p, n) \
Maybe it's just me, but the name is ugly.
> + do { \
> + struct __scrub { char c[n]; }; \
Better typeof(*p)[n]
> +++ b/include/linux/compiler-intel.h
> @@ -14,9 +14,11 @@
> * It uses intrinsics to do the equivalent things.
> */
> #undef barrier
> +#undef ARRAY_PREVENT_DSE
> #undef RELOC_HIDE
>
> #define barrier() __memory_barrier()
> +#define ARRAY_PREVENT_DSE(p, n)
Who says the Intel compiler doesn't need this?
I'm sure it does dead store elimination too and it understands
gcc asm syntax.
> +/**
> + * secure_bzero - Call memset to fill a region of memory with zeroes and
> + * ensure this memset is not removed due to dead store elimination.
> + * @p: Pointer to the start of the area.
> + * @n: The size of the area.
> + */
> +void secure_bzero(void *p, size_t n)
> +{
> + memset(p, 0, n);
> + ARRAY_PREVENT_DSE(p, n);
I think that's a candidate for a inline
-Andi
--
ak@linux.intel.com -- Speaking for myself only.
next prev parent reply other threads:[~2010-02-28 9:55 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-02-27 20:47 [PATCH v1] compiler: prevent dead store elimination Roel Kluin
2010-02-28 9:55 ` Andi Kleen [this message]
2010-02-28 15:34 ` [PATCH v2] " Roel Kluin
2010-03-01 9:29 ` Mikael Pettersson
2010-03-02 12:17 ` Andi Kleen
2010-03-03 23:16 ` [PATCH v3] " Roel Kluin
2010-03-02 12:24 ` [PATCH v2] " Andi Kleen
2010-03-01 0:36 ` [PATCH v1] " Bill Davidsen
2010-03-01 5:15 ` Arjan van de Ven
2010-03-01 9:32 ` Mikael Pettersson
2010-03-01 9:33 ` Alexey Dobriyan
2010-03-01 22:27 ` Andi Kleen
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=20100228095520.GA29531@one.firstfloor.org \
--to=andi@firstfloor.org \
--cc=Herbert@gondor.apana.org.au \
--cc=akpm@linux-foundation.org \
--cc=brgerst@gmail.com \
--cc=davem@davemloft.net \
--cc=linux-crypto@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mikpe@it.uu.se \
--cc=penberg@cs.helsinki.fi \
--cc=roel.kluin@gmail.com \
/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;
as well as URLs for NNTP newsgroup(s).