Hacker News Reader

Comment by bonzini | Hacker News Reader

systemd does store the entropy in a file, but Lennart says this in the comments of the article: "we can only credit a random seed read from disk when we can also update it on disk, so that it is never reused. This means /var needs to be writable, which is really later during boot, long after we already needed entropy".

How does OpenBSD deal with this issue?

View on HN

From rc(8):

  # Push the old seed into the kernel, create a future seed  and create a seed
  # file for the boot-loader.
  random_seed() {
        dd if=/var/db/host.random of=/dev/random bs=65536 count=1 status=none
        chmod 600 /var/db/host.random
        dd if=/dev/random of=/var/db/host.random bs=65536 count=1 status=none
        dd if=/dev/random of=/etc/random.seed bs=512 count=1 status=none
        chmod 600 /etc/random.seed
  }

* https://cvsweb.openbsd.org/src/etc/rc?rev=1.537

FreeBSD:

* https://svnweb.freebsd.org/base/head/libexec/save-entropy/

* https://www.freebsd.org/cgi/man.cgi?loader.conf(5) (see "entropy_cache_load")

OpenBSD's boot loader also injects entropy into the kernel.

Which is to say, /var/ is writable when they do it.

This business of /var/ not being writable early enough is probably to do with the wonderful complexities of modern Linux, and is just not a problem that OpenBSD has.

This is a fancy way of saying it's systemd's fault. (/s)

What if a filesystem error forces /var (or whichever mount point hosts the entropy seed) to remain read-only and seed is never replaced? Seems like unlike systemd the BSDs are fine with crediting entropy even if it has been used already in a previous boot. That's wrong though.

> Seems like unlike systemd the BSDs are fine with crediting entropy even if it has been used already in a previous boot.

FreeBSD runs a regular cron job so that there are multiple files. If /var goes R-O, you still have a bunch of files from when it wasn't and they are not the same as on initial boot (assuming that (a) /var was mounted R-W at some point, and (b) cron managed to run as well).

Also, on shutdown there is an attempt to write 4096B to both /entropy and /boot/entropy:

* https://svnweb.freebsd.org/base/head/libexec/rc/rc.d/random?...

Further, all of these various seed files are not the only sources of entropy (timers, RDRAND, etc).

> (assuming that (a) /var was mounted R-W at some point

Not a good assumption if the initial r/w mount is the one that fails...

If the initial /var (or /) is broken, then one has bigger problems and probably has to go in manually to fix things.

But for >99% of cases where the system comes up cleanly, and runs cleanly for a period of time, you'll have a bunch of seed files ready to go for the next boot. This configuration optimizes for the common case.

> Which is to say, /var/ is writable when they do it.

They also do it at shutdown, before /var is R/O or unmounted.

One can also have multiple files, and have a regular cron job that replaces one of them occasionally while the system is running. This is what the FreeBSD script does.

* https://svnweb.freebsd.org/base/head/libexec/save-entropy/

* https://svnweb.freebsd.org/base/head/libexec/rc/rc.d/random

Other systems have solved this problem, so I'm not sure why all the high drama with Linux.

FreeBSD saves entropy in two places; the one you've linked is only loaded after userspace starts (via rc.d/random). The boot-time entropy mentioned in loader.conf is also created and saved in rc.d/random:

https://svnweb.freebsd.org/base/head/libexec/rc/rc.d/random?...

Similar idea to what OpenBSD does.

Read the seed on boot, replace it when possible.

It's also said that adding entropy to the pool can never make it worse, no? So why not just add it anyway. If you get to replace it, great! If not, well you tried.

Yes, but you should not credit the entropy you added if you're not sure it's never been used before. And you need to credit it to avoid hangs.

OpenBSD doesn't have systemd.

The boot-loader injects randomness into the kernel before starting the kernel (using the saved random seed file), so you can have randomness from the very first bit of initialization.

If you cannot guarantee that the entropy has never been used before, that's bad.

It is guaranteed to not be worse than no injected entropy at all, which is the default and only possible alternative state before the kernel starts, it always gets mixed with what can be gathered.

Reply on news.ycombinator.com