Roel Kluin writes: > > > > Does this optimization also occur during compilation of the Linux > > > kernel? > > > Any such dead store removal is up to the compiler and the lifetime > > of the object being clobbered. For 'auto' objects the optimization > > is certainly likely. > > > > This is only a problem if the memory (a thread stack, say) is recycled > > and leaked uninitialized to user-space, but such bugs are squashed > > fairly quickly upon discovery. > > Thanks for comments, > > In the sha1_update() case I don't know whether the stack is recycled and > leaked - it may be dependent on the calling function, but isn't it > vulnerable? It's only vulnerable if the data leaks to a less trusted domain. There is no domain crossing in your user-space example. In the kernel case, the domain crossing would be as I wrote: leaking recycled and uninitialized memory to user-space (and those leaks of uninitialized memory are frowned upon and quickly fixed when discovered). -- 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
