Mikael Pettersson writes:
> Andi Kleen writes:
> > roel kluin <roel.kluin@xxxxxxxxx> writes:
> >
> > >> And it's wrong because the reason the memset() is there seems to be
> > >> to clear out key information that might exist kernel stack so that
> > >> it's more difficult for rogue code to get at things.
> > >
> > > If the memset is optimized away then the clear out does not occur. Do you
> > > know a different way to fix this? I observed this with:
> >
> > You could always cast to volatile before memsetting?
>
> I tried that and it doesn't work. Furthermore passing a volatile void *
> to a function expecting a void * provokes a compiler warning.
>
> I currently think that defining and using
>
> void secure_bzero(void *p, size_t n)
> {
> memset(p, 0, n);
> /* We need for this memset() to be performed even if *p
> * is about to disappear (a local auto variable going out
> * of scope or some dynamic memory being kfreed()).
> * Thus we need to fake a "use" of *p here.
> * barrier() achieves that effect, and much more.
> * TODO: find a better alternative to barrier() here.
> */
> barrier();
Instead of barrier(), this works with gcc-3.2.3 up to gcc-4.4.3
for the purpose of making the memset() not disappear:
{
struct s { char c[n]; };
asm("" : : "m"(*(struct s *)p));
}
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.
An explicit loop that uses each byte individually also works, but
results in awful code with older compilers.
> }
--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
