5 ms·

Does anybody who is familiar with the BSDs know how those OSes solve this kind of problem? (I don't know enough to say if this even could be a problem with thei

Does anybody who is familiar with the BSDs know how those OSes solve this kind of problem? (I don't know enough to say if this even could be a problem with their architecture, just curious).

throw0101a 7y ago
The boot loaders read entropy off-disk to seed the kernel: * https://www.freebsd.org/cgi/man.cgi?loader.conf(5) https://www.freebsd.org/cgi/man.cgi?loader.conf(5) (see "entropy_cache_load") When the system is brought down cleanly (init 0 or 6) a seed file is saved. Also, when the system is started up, a seed file is created in case there's a crash. OpenBSD's 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 also has a cron job that saves 4KB of entropy every 11 minutes in a rotating series of files: * https://svnweb.freebsd.org/base/head/libexec/save-entropy/ https://svnweb.freebsd.org/base/head/libexec/save-entropy/ * https://svnweb.freebsd.org/base/head/libexec/rc/rc.d/random https://svnweb.freebsd.org/base/head/libexec/rc/rc.d/random
- beefhash 7y ago
  The installer also leaves a random.seed file so that there's a direct chain from the very first boot.
  - throw0101a 7y ago
    So the main remaining risk is things like (cloud) images where many people/machines use the same seed. This can be mitigated by stirring in RDRAND, unique CPU information (serial number?), high-res date/time, and other possibly unique information (MAC addresses?).
    - anjbe 7y ago
      If you’re running virtual machines you can just use a virtual RNG device exposed by the hypervisor.
      - wahern 7y ago
        The Virtio RNG driver was merged into Linux 2.6.26, released a decade ago. AFAIU it should be built into most Linux kernels. I just confirmed on Alpine 3.10 and Ubuntu 18.10 (Cosmic). The problem is that not all hypervisors provide the device by default. I use libvirt KVM/QEMU and the default template doesn't include it, but you can add it. AWS EC2 doesn't provide it, though it doesn't provide any virtio devices. Parallels Desktop 15 doesn't support virtio-rng, either OTOH, OpenBSD's VMD not only supports it but I think it's enabled by default. (I see it in the source code. I can't find a way to enable/disable it, but the publicly posted dmesg dumps seem to always show it as found when an OpenBSD guest boots.) Of course, most VMs are x86_64-based using hardware extensions and likely using CPUs providing rdrand. But hypervisors really should provide the virtio-rng device default, perhaps even unconditionally as OpenBSD apparently does.
        anjbe 7y ago
        > OTOH, OpenBSD's VMD not only supports it but I think it's enabled by default. Yes, my VMD virtual machines have it with no configuration necessary. pvbus0 at mainbus0: OpenBSD pci0 at mainbus0 bus 0 virtio0 at pci0 dev 1 function 0 "Qumranet Virtio RNG" rev 0x00 viornd0 at virtio0 Here’s the manpage: https://man.openbsd.org/viornd.4 https://man.openbsd.org/viornd.4
- the_why_of_y 7y ago
  It's this kind of problem, but it's not the same problem; the Linux problem under discussion happens at a point during the boot when /var is not yet accessible/writable.
  - throw0101a 7y ago
    You drop an entropy file in /boot and have GRUB seed it into the kernel. The file is created (a) when the system is shutdown cleanly, but also (b) when the system comes up cleanly in case of a crash later on.

Does anybody who is familiar with the BSDs know how those OSes solve this kind of problem? (I don't know enough to say if this even could be a problem with their architecture, just curious).

throw0101a 7y ago

The boot loaders read entropy off-disk to seed the kernel: * https://www.freebsd.org/cgi/man.cgi?loader.conf(5) https://www.freebsd.org/cgi/man.cgi?loader.conf(5) (see "entropy_cache_load") When the system is brought down cleanly (init 0 or 6) a seed file is saved. Also, when the system is started up, a seed file is created in case there's a crash. OpenBSD's 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 also has a cron job that saves 4KB of entropy every 11 minutes in a rotating series of files: * https://svnweb.freebsd.org/base/head/libexec/save-entropy/ https://svnweb.freebsd.org/base/head/libexec/save-entropy/ * https://svnweb.freebsd.org/base/head/libexec/rc/rc.d/random https://svnweb.freebsd.org/base/head/libexec/rc/rc.d/random

beefhash 7y ago
The installer also leaves a random.seed file so that there's a direct chain from the very first boot.
- throw0101a 7y ago
  So the main remaining risk is things like (cloud) images where many people/machines use the same seed. This can be mitigated by stirring in RDRAND, unique CPU information (serial number?), high-res date/time, and other possibly unique information (MAC addresses?).
  - anjbe 7y ago
    If you’re running virtual machines you can just use a virtual RNG device exposed by the hypervisor.
    - wahern 7y ago
      The Virtio RNG driver was merged into Linux 2.6.26, released a decade ago. AFAIU it should be built into most Linux kernels. I just confirmed on Alpine 3.10 and Ubuntu 18.10 (Cosmic). The problem is that not all hypervisors provide the device by default. I use libvirt KVM/QEMU and the default template doesn't include it, but you can add it. AWS EC2 doesn't provide it, though it doesn't provide any virtio devices. Parallels Desktop 15 doesn't support virtio-rng, either OTOH, OpenBSD's VMD not only supports it but I think it's enabled by default. (I see it in the source code. I can't find a way to enable/disable it, but the publicly posted dmesg dumps seem to always show it as found when an OpenBSD guest boots.) Of course, most VMs are x86_64-based using hardware extensions and likely using CPUs providing rdrand. But hypervisors really should provide the virtio-rng device default, perhaps even unconditionally as OpenBSD apparently does.
      - anjbe 7y ago
        > OTOH, OpenBSD's VMD not only supports it but I think it's enabled by default. Yes, my VMD virtual machines have it with no configuration necessary. pvbus0 at mainbus0: OpenBSD pci0 at mainbus0 bus 0 virtio0 at pci0 dev 1 function 0 "Qumranet Virtio RNG" rev 0x00 viornd0 at virtio0 Here’s the manpage: https://man.openbsd.org/viornd.4 https://man.openbsd.org/viornd.4
the_why_of_y 7y ago
It's this kind of problem, but it's not the same problem; the Linux problem under discussion happens at a point during the boot when /var is not yet accessible/writable.
- throw0101a 7y ago
  You drop an entropy file in /boot and have GRUB seed it into the kernel. The file is created (a) when the system is shutdown cleanly, but also (b) when the system comes up cleanly in case of a crash later on.