[systemd-devel] Delaying (SSH) key generation until the urandom pool is initialized

[Lennart Poettering]

On Fri, 02.05.14 13:19, Florian Weimer (fweimer at 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