On Tue, Nov 12, 2013 at 05:40:09PM -0500, Greg Price wrote: > > Beyond these easy cleanups, I have a couple of patches queued up (just > written yesterday, not quite finished) to make /dev/urandom block at > boot until it has enough entropy, as the "Mining your P's and Q's" > paper recommended and people have occasionally discussed since then. > Those patches were definitely for after 3.13 anyway, and I'll send > them when they're ready. I see some notifications and warnings in > this direction in the random.git tree, which is great.
One of the things I've been thinking about with respect to making /dev/urandom block is being able to configure (via a module parameter which could be specified on the boot command line) which allows us to set a limit for how long /dev/urandom will block after which we log a high priority message that there was an attempt to read from /dev/urandom which couldn't be satisified, and then allowing the /dev/urandom read to succed. The basic idea is that we don't want to break systems, but we do want to gently coerce people to do the right thing. Otherwise, I'm worried that distros, or embedded/mobile/consume electronics engineers would just patch out the check. If we make the default be something like "block for 5 minutes", and then log a message, we won't completely break a user who is trying to login to a VM, but it will be obvious, both from the delay and from the kern.crit log message, that there is a potential problem here that a system administrator needs to worry about. - 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/