On Wed, 30.04.14 14:02, Florian Weimer (fwei...@redhat.com) wrote: > > On 04/30/2014 01:08 PM, Lennart Poettering wrote: > >On Tue, 29.04.14 20:43, Florian Weimer (fwei...@redhat.com) wrote: > > > >>The message at > >><https://mail.gnome.org/archives/ostree-list/2014-February/msg00010.html> > >>contains two boot traces from virtual machines which show that the > >>SSH key is generated before the kernel pool is sufficiently seeded. > > > >Are you saying ssh reads from /dev/urandom rather than /dev/random, but > >it should be reading from the latter? > > No, that's not what I wrote. > > Using /dev/urandom for key generation is fine once its pool is > seeded. Using existing key generation algorithms with /dev/random > instead does not work because they consume too much entropy and can > block for significantly more time than just a few minutes. > > >WHat does that have to do with systemd? > > It seems related to boot ordering, device availability, kernel event > signaling and so on (although we have little of that at present). > > In particular, what I want is that a one-shot service for key > generation only blocks on pool seeding when it actually needs to run > (because the keys do not exist yet). From a support perspective, it > seems better to do the waiting outside the one-shot service, so that > systemd tools can be used to examine what is causing the delay. > > >>Would it be possible using socket activation to create the listening > >>socket for SSH, but block the actual service startup until the keys > >>have been generated after sufficient entropy became available? > >> > >>What would you need on the kernel side to implement the waiting? > >>(Textual comparison of a log message is only good for a prototype.) > > > >THis already exists. It's called /dev/random... > > No, /dev/random can (and will) block long after booting.
But that's what you want in this case, no? You want this to block after booting if there never has been enough entropy in the pool, right? Is there any kernel API currently available to at least query if the pool is properly initialized? So you have multiple options: a) fix the kernel to make /dev/urandom block until enough initial entropy has been gathered. Would fix the roblem, but probably slow down systemd. In systemd the hash functions used in hash tables are keyed off /dev/urandom, in order to make collision attacks difficult. This only requires low-quality entropy, as we rehash with a new key anyway should the hashtable reach its initial size limit. Hence blocking reading of /dev/urandom until the pool is initialized will slow down systemd since would have to block without actually needing any quality entropy... b) fix the kernel to make the behaviour explained in a) something optional, maybe something that is enabled on /dev/random when O_DIRECT or so is passed during opening. i.e. if that flag is specifiied that /dev/random will behave like classic /dev/random until the initial pool is filled up, and like /dev/urandom afterwards. c) solve this in userspace in the individual apps. if there's a kernel api to check whether the pool is properly initialized, then apps could check that. If the check fails they'd use /dev/random, otherwise /dev/urandom. I am very conservative howver to simply delay the boot until the pool is initialized. Lennart -- Lennart Poettering, Red Hat _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
