On Tue, Apr 29, 2014 at 07:51:08PM +0200, Florian Weimer wrote: > > I've got a (physical) machine where it happens after ten seconds, or much > longer if there is no activity. > > I've seen cases where on the first boot of virtual machines, the SSH key was > generated before the printk with the initialization message. It's not a > problem if you install the OS first and then generate the keys, but for > booting from pre-provisioned images, it could be. (I have no evidence that > this hurts the quality of the generated key material, this is just based on > what's reported by the kernel.)
Yes, fair enough, just because it works for me for my laptops doesn't mean that there aren't systems for which it was a problem. :-) I will say that for virtual machines, we *really* need virtio-rng. And I wonder if the right answer is that initially we have some other process listening on the ssh port, which can generate the ssh host keys when someone actually first connects to the ssh port (since at that point, networking will have come up and we'll get some entropy just from the networking interupts if nothing else), and then exec the real ssh daemon to handle the incoming connection, as well as execing a the real ssh daemon to take over listening on the ssh port. > I'm not sure if I want to bet an increasingly crucial part of the boot > design on the continuing availability of the current entropy levels (which > could go down as the result of environmental changes or a reassessment of > the entropy that actually comes into the system). It doesn't matter of entropy levels go down; what's important is that at least at one point, the entropy estimate goes above the threshold level. Once that happens, someone can only break the RNG if (a) we were wrong about the entropy estimate --- and we've made the entropy estimator extremely conservative for that reason; the academic papers which have studied /dev/random have not found fault with the estimator, or (b) someone has broken the underlying crypto algorithm. > Or a new /dev/?random device that blocks until initialized, but behaves just > like /dev/urandom after that. The question is how useful it would be > because of the deadlock scenario. It's like any other technology; it depends on how you use it. If you don't block the whole boot, but just those services which depend on the entropy generation (for example, ssh), and there's enough services up so that the machine has activity so that eventually the initialized flag is set, it won't be a deadlock. Maybe it will take five minutes before the machine is answering ssh queries, and that could be a support nightmare, sure. At some level, it's up to use to generate a system that can generate enough entropy in a reasonable time, which is why I added the printk in the first place -- to assist in that effort. So if you're not going to block on the urandom generator being "initialized" (where the definition, like the entropy estimator, is somewhat arbitrary), how were you thinking the information from /proc/sys/kernel/random/intialized would be used? - 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/