On Sat, Jul 07, 2012 at 10:11:22AM -0700, Kees Cook wrote: > While very unlikely, it is possible for arch_get_random_long() to fail > in the middle of the loop in xfer_secondary_pool(), which would mean > that the loop could stop with only part of u.hwrand populated, leading > to mix_pool_bytes() injecting uninitialized or already injected bytes > instead of fresh bytes. This changes the mix_pool_bytes() call to only > inject the successfully gathered bytes.
I don't believe there is a major problem with injecting uninitialized or even known bytes into the pool; worst case we're wastiing a tiny amount of CPU in this unlikely case (versus the CPU costs of doing the multiplication each time). Not that I think really matters one way or the other... Is there a reason why you're particularly concerned about what might happen in the case where arch_get_random_long() fails mid-loop (which can happen if RDRAND returns an error for whatever reason, granted)? Regards, - Ted -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/