On Mon, 8 Sep 2014, Hannes Frederic Sowa wrote:

> On So, 2014-09-07 at 23:23 +0200, Daniel Borkmann wrote:
> > Recently, in commit 13aa93c70e71 ("random: add and use memzero_explicit()
> > for clearing data"), we have found that GCC may optimize some memset()
> > cases away when it detects a stack variable is not being used anymore
> > and going out of scope. This can happen, for example, in cases when we
> > are clearing out sensitive information such as keying material or any
> > e.g. intermediate results from crypto computations, etc.
> >
> > With the help of Coccinelle, we can figure out and fix such occurences
> > in the crypto subsytem as well. Julia Lawall provided the following
> > Coccinelle program:
> >
> >   @@
> >   type T;
> >   identifier x;
> >   @@
> >
> >   T x;
> >   ... when exists
> >       when any
> >   -memset
> >   +memzero_explicit
> >      (&x,
> >   -0,
> >      ...)
> >   ... when != x
> >       when strict
> >
> >   @@
> >   type T;
> >   identifier x;
> >   @@
> >
> >   T x[...];
> >   ... when exists
> >       when any
> >   -memset
> >   +memzero_explicit
> >      (x,
> >   -0,
> >      ...)
> >   ... when != x
> >       when strict
>
> I think this Coccinelle patch won't make it completely unnecessary for a
> manual audit as it does not take optimizations (dead code eliminitation)
> into account?

I agree.  If you see something else that could be taken into account in
the semantic patch, please let me know.

julia


>
> >
> > Therefore, make use of the drop-in replacement memzero_explicit() for
> > exactly such cases instead of using memset().
> >
> > Signed-off-by: Daniel Borkmann <dbork...@redhat.com>
> > Cc: Julia Lawall <julia.law...@lip6.fr>
> > Cc: Herbert Xu <herb...@gondor.apana.org.au>
> > Cc: Theodore Ts'o <ty...@mit.edu>
> > Cc: Hannes Frederic Sowa <han...@stressinduktion.org>
>
> Acked-by: Hannes Frederic Sowa <han...@stressinduktion.org
>
> Thanks,
> Hannes
>
>
>
--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to