On Wed, Aug 13, 2014 at 7:32 AM, Theodore Ts'o <tytso@xxxxxxx> wrote: > On Wed, Aug 13, 2014 at 12:48:41AM -0700, H. Peter Anvin wrote: >> The proposed arch_get_rng_seed() is not really what it claims to be; it >> most definitely does not produce seed-grade randomness, instead it seems >> to be an arch function for best-effort initialization of the entropy >> pools -- which is fine, it is just something quite different. > > Without getting into an argument about which definition of "seed" is > correct --- it's certainly confusing and different form the RDSEED > usage of the word "seed". > > Do we expect that anyone else besides arch_get_rnd_seed() would > actually want to use it? If you mean random.c instead of arch_get_rnd_seed, then I don't expect there to be other users. Aside from the "best-effort" bit causing this to be basically useless on old bare metal, the interface is really awkward for anything other than the use in random.c. > I'd argue no; we want the rest of the kernel > to either use get_random_bytes() or prandom_u32(). Given that, maybe > we should just call it arch_random_init(), and expect that the only > user of this interface would be drivers/char/random.c? Sounds good to me. FWIW, I'd like to see a second use added in random.c: I think that we should do this, or even all of init_std_data, on resume from suspend and especially on resume from hibernate / kexec. --Andy -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
