On Fri, 02.05.14 13:19, Florian Weimer (fwei...@redhat.com) wrote: > > On 05/02/2014 01:05 PM, Lennart Poettering wrote: > > >>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? > > What I want is no blocking at all.
Not following here... I mean, you *do* want some blocking here, so that the SSH key is generated with the pool initialized, right? > >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... > > If systemd is blocked on /dev/urandom at this stage, will anything > else happen on the system that generates more entropy? Nope. systemd starts allocating those hashtables very very early on, before any process is forked off... It's par tof the initialization scheme of systemd really. Hence there's basically nothing else going on in the system, execept what is done by the kernel itself... > > >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. > > Or perhaps a separate device node. I'd strongly recommend against that. There's a lot of code that sets up a chroot-style environment with a minimal /dev, which only contains the "API" device nodes, such as /dev/null, /dev/zero, /dev/random and /dev/urandom. For example, systemd exposes that easily reachable via PrivateDevices=yes, and so do many container manages. Adding a new device node like this would mean patching all the code that sets up environments like this... I'd really prefer if this could be just some different way how to open the existing device node, so that this creates no headache. (Actually, I'd even prefer if /dev/random and /dev/urandom were the same device node...) > >I am very conservative howver to simply delay the boot until the pool is > >initialized. > > I want this for specific services only. For things like hash > tables, it's possible to reseed once more randomness becomes > available, but that's not true for long-term key generation. I am pretty sure it shouldn't be systemd that delays invocation of these specific services. instead it should be the RNG device node that delays reading from it. This is simpler and given that the kernel already supports both the /dev/random and /dev/urandom access styles, looks like the most appropriate place. Lennart -- Lennart Poettering, Red Hat _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
