Am Sonntag, 24. April 2016, 23:25:00 schrieb Pavel Machek: Hi Pavel, > > /* This RNG does not work if no high-resolution timer is available */ > > BUG_ON(!random_get_entropy() && !random_get_entropy()); > > Heh, does this cause BUG() with 2^-64 probability? :-). No, but for the listed arches, get_cycles would return 0. And I only call the function twice to not be tripped by a potential wrap around at the time of calling. > > > If there is no high-resolution timer, the LRNG will not produce good > > entropic random numbers. The current kernel code implements > > high-resolution timers for all but the following architectures where > > neither random_get_entropy nor > > get_cycles are implemented: > Ok, what about stuff like Intel 486 (no RDTSC)? > > > Thus, for all large-scale architectures, the LRNG would be applicable. > > > > Please note that also the legacy /dev/random will have hard time to obtain > > entropy for these environments. The majority of the entropy comes > > from high- > > Understood. > > > Though, the patch I offer leaves the legacy /dev/random in peace for those > > architectures to not touch the status quo. > > Well -- that's the major problem -- right? Makes it tricky to tell > what changed, and we had two RNGs to maintain. I would rather think that even the legacy /dev/random should not return any values in those environments. The random numbers that are returned on these systems are bogus, considering that the only noise source that could deliver some entropy excluding timestamps (if you trust the user) are the HID event values. And for those listed systems, I doubt very much that they are used in a desktop environment where you have a console. If everybody agrees, I can surely add some logic to make the LRNG working on those systems. But those additions cannot be subjected to a thorough entropy analysis. Yet I feel that this is wrong. My goal with the LRNG is to provide a new design using proven techniques that is forward looking. I am aware that the design does not work in circumstances where the high-res timer is not present. But do we have to settle on the least common denominator knowing that this one will not really work to begin with? Ciao Stephan -- 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
