[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <19334.42332.984074.920727@pilspetsen.it.uu.se>
Date: Thu, 25 Feb 2010 17:29:16 +0100
From: Mikael Pettersson <mikpe@...uu.se>
To: Pekka Enberg <penberg@...helsinki.fi>
Cc: Mikael Pettersson <mikpe@...uu.se>,
Roel Kluin <roel.kluin@...il.com>,
Herbert Xu <herbert@...dor.apana.org.au>,
"David S. Miller" <davem@...emloft.net>,
linux-crypto@...r.kernel.org,
Andrew Morton <akpm@...ux-foundation.org>,
LKML <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] sha: prevent removal of memset as dead store in
sha1_update()
Pekka Enberg writes:
> On Thu, Feb 25, 2010 at 5:56 PM, Mikael Pettersson <mikpe@...uu.se> wrote:
> > I fear that the only portable (across compiler versions) and safe
> > solution is to invoke an assembly-coded dummy function with prototype
> >
> > void use(void *p);
> >
> > and rewrite the code above as
> >
> > {
> > u32 temp[...];
> > ...
> > memset(temp, 0, sizeof temp);
> > use(temp);
> > }
> >
> > This forces the compiler to consider the buffer live after the
> > memset, so the memset cannot be eliminated.
>
> So is there some "do not optimize" GCC magic that we could use for a
> memzero_secret() helper function?
I guess there's some -fno-builtin-... that might achieve this effect,
but that would disable all memset optimizations, not just those affecting
sensitive data.
You'd want a function attribute or magic type annotation and apply it
only to the specific cases where it's needed. Alas, I know of no such
attribute or annotation. ('volatile' doesn't work, I tried that.)
Ask on gcc@....gnu.org.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists