5 ms·

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 als

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?

tedunangst 7y ago
Read the seed on boot, replace it when possible.
magicalhippo 7y ago
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.
- bonzini 7y ago
  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.
throw0101a 7y ago
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 https://cvsweb.openbsd.org/src/etc/rc?rev=1.537 FreeBSD: * https://svnweb.freebsd.org/base/head/libexec/save-entropy/ https://svnweb.freebsd.org/base/head/libexec/save-entropy/ * https://www.freebsd.org/cgi/man.cgi?loader.conf(5) https://www.freebsd.org/cgi/man.cgi?loader.conf(5) (see "entropy_cache_load") OpenBSD's boot loader also injects entropy into the kernel.
- devnulloverflow 7y ago
  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.
  - asveikau 7y ago
    This is a fancy way of saying it's systemd's fault. (/s)
  - bonzini 7y ago
    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.
    - throw0101a 7y ago
      > 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?revision=348122&view=markup 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).
      - bonzini 7y ago
        > (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...
throwaway2048 7y ago
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.
- bonzini 7y ago
  If you cannot guarantee that the entropy has never been used before, that's bad.
  - throwaway2048 7y ago
    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.
sverige 7y ago
OpenBSD doesn't have systemd.

tedunangst 7y ago

Read the seed on boot, replace it when possible.

magicalhippo 7y ago

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.

bonzini 7y ago
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.

throw0101a 7y ago

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 https://cvsweb.openbsd.org/src/etc/rc?rev=1.537 FreeBSD: * https://svnweb.freebsd.org/base/head/libexec/save-entropy/ https://svnweb.freebsd.org/base/head/libexec/save-entropy/ * https://www.freebsd.org/cgi/man.cgi?loader.conf(5) https://www.freebsd.org/cgi/man.cgi?loader.conf(5) (see "entropy_cache_load") OpenBSD's boot loader also injects entropy into the kernel.

devnulloverflow 7y ago
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.
- asveikau 7y ago
  This is a fancy way of saying it's systemd's fault. (/s)
- bonzini 7y ago
  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.
  - throw0101a 7y ago
    > 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?revision=348122&view=markup 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).
    - bonzini 7y ago
      > (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...

throwaway2048 7y ago

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.

bonzini 7y ago
If you cannot guarantee that the entropy has never been used before, that's bad.
- throwaway2048 7y ago
  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.

sverige 7y ago

OpenBSD doesn't have systemd.