Re: [PATCH] sha: prevent removal of memset as dead store in sha1_update()

[Mikael Pettersson]

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-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/