On Sat, Oct 04, 2014 at 11:09:40PM -0400, Sandy Harris wrote: > There was recently a patch to the random driver to replace memset() > because, according to the submitter, gcc sometimes optimises memset() > away which might leave data unnecessarily exposed. The solution > suggested was a function called memzero_explicit(). There was a fair > bit of discussion and the patch was accepted. Do you have a pointer? > In the crypto directory of the kernel source I have: > > $ grep memset *.c | wc -l > 133 > $ > > I strongly suspect some of these should be fixed. It seems this is a common topic: http://www.daemonology.net/blog/2014-09-04-how-to-zero-a-buffer.html and part 2: http://www.daemonology.net/blog/2014-09-06-zeroing-buffers-is-insufficient.html Summary: It's not just the memory we should be concerned about, there's also the stack and the registers. memzero_explicit() is a good start, but I think the articles raise two important points. a) register data temporarily stored on the stack via compiler optimizations, and b) aesni register contents left behind after use. I suspect (a) is an unquantified problem on embedded systems, and (b) may extend to embedded hardware crypto implementations. thx, Jason. -- 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
