6 ms·

What reasons are there not to implement the OpenBSD model where the bootloader passes the kernel a seed that the kernel generated previously?

IcePic 8y ago
There is no reason not to try it, but you would still want to cater for the initial boot when you have no previous entropy to read.
- hsivonen 8y ago
  Couldn't the installer write the initial seed?
  - ddtaylor 8y ago
    It's seeds all the way down.
  - chopin 8y ago
    There's not always an installer, I make heavily use of live images. On other machines of mine, first boot is made from a copied image.
    - jlgaddis 8y ago
      You may know this but for others who may not: there are tools like virt-sysprep that can (among other things) inject a random seed into disk images. If you clone/generate VMs from one "master" image, running virt-sysprep (or similar) is one of the steps you should do right before launching a new instance (inject a new random seed, wipe out any SSH host keys, etc.) Even DigitalOcean missed doing this step a while back.
      - JdeBP 8y ago
        I was about to mention the same thing. A pass to make an image unique before bootstrapping it is, or should be, a well-known thing. Remember the hoo-hah over unique machine SIDs in Windows NT. And there is of course the Freedesktop world's systemd-firstboot for making unique machine IDs in images in D-Bus and systemd.
    - dspillett 8y ago
      If you have network access early enough in the install and/or boot processes could you not pluck some random bits from a web service to pump more entropy into the RNG's pool? For paranoia you could host your own fairly easily instead of using a public one: have a machine that is publicly visible respond with random digits from its own entropy pool, have it use one or more of various methods to keep that pool topped up (local interrupt timings, a hardware RNG, ...), use request hashing with a "secret" key if you are worried about the general public draining your entropy pool or available bandwidth. And if it can't see the entropy service for any reason (it is booting in an environment where the rest of the network is completely cut off, or perhaps the entropy service is down) then fall back to just doing what-ever is done now.
      - dsl 8y ago
        http://manpages.ubuntu.com/manpages/trusty/man1/pollinate.1.html http://manpages.ubuntu.com/manpages/trusty/man1/pollinate.1....
        dspillett 8y ago
        Exactly that. I'd not spotted that a nice convenient option already existed rather than rolling your own. If the location you host pollen on to provide entropy for elsewhere via pollenate, try running haveged.
tytso 8y ago
The reason why this is hard is because Linux is supported on a great number of architectures, and some architectures have more than one boot loader that is used. The approach of letting the bootloader pass seed entropy is the right answer in general, I agree, but unlike OpenBSD we can't assume that it will always be present. (OpenBSD only supports a limited number of architectures, and a single bootloader.) Hence, no matter what, we have to have fallback mechanisms for dealing with the case where we have a bootloader which doesn't pass a seed to the kernel. The other issue is that I don't get paid to work on the random driver in Linux. I've been looking for volunteers to work with the grub, syslinux, efistub, not to mention all of the various signed bootloaders used by different Android devices, but because we had a fallback mechanism there is less motivation for people to want to work on this. This would actually be a great intern project or GSOC project, but this have been so hectic this year, personally and professionally, I didn't have the time to commit to hosting an intern or GSOC student this summer. :-(

IcePic 8y ago

There is no reason not to try it, but you would still want to cater for the initial boot when you have no previous entropy to read.

hsivonen 8y ago
Couldn't the installer write the initial seed?
- ddtaylor 8y ago
  It's seeds all the way down.
- chopin 8y ago
  There's not always an installer, I make heavily use of live images. On other machines of mine, first boot is made from a copied image.
  - jlgaddis 8y ago
    You may know this but for others who may not: there are tools like virt-sysprep that can (among other things) inject a random seed into disk images. If you clone/generate VMs from one "master" image, running virt-sysprep (or similar) is one of the steps you should do right before launching a new instance (inject a new random seed, wipe out any SSH host keys, etc.) Even DigitalOcean missed doing this step a while back.
    - JdeBP 8y ago
      I was about to mention the same thing. A pass to make an image unique before bootstrapping it is, or should be, a well-known thing. Remember the hoo-hah over unique machine SIDs in Windows NT. And there is of course the Freedesktop world's systemd-firstboot for making unique machine IDs in images in D-Bus and systemd.
  - dspillett 8y ago
    If you have network access early enough in the install and/or boot processes could you not pluck some random bits from a web service to pump more entropy into the RNG's pool? For paranoia you could host your own fairly easily instead of using a public one: have a machine that is publicly visible respond with random digits from its own entropy pool, have it use one or more of various methods to keep that pool topped up (local interrupt timings, a hardware RNG, ...), use request hashing with a "secret" key if you are worried about the general public draining your entropy pool or available bandwidth. And if it can't see the entropy service for any reason (it is booting in an environment where the rest of the network is completely cut off, or perhaps the entropy service is down) then fall back to just doing what-ever is done now.
    - dsl 8y ago
      http://manpages.ubuntu.com/manpages/trusty/man1/pollinate.1.html http://manpages.ubuntu.com/manpages/trusty/man1/pollinate.1....
      - dspillett 8y ago
        Exactly that. I'd not spotted that a nice convenient option already existed rather than rolling your own. If the location you host pollen on to provide entropy for elsewhere via pollenate, try running haveged.

tytso 8y ago

The reason why this is hard is because Linux is supported on a great number of architectures, and some architectures have more than one boot loader that is used. The approach of letting the bootloader pass seed entropy is the right answer in general, I agree, but unlike OpenBSD we can't assume that it will always be present. (OpenBSD only supports a limited number of architectures, and a single bootloader.) Hence, no matter what, we have to have fallback mechanisms for dealing with the case where we have a bootloader which doesn't pass a seed to the kernel. The other issue is that I don't get paid to work on the random driver in Linux. I've been looking for volunteers to work with the grub, syslinux, efistub, not to mention all of the various signed bootloaders used by different Android devices, but because we had a fallback mechanism there is less motivation for people to want to work on this. This would actually be a great intern project or GSOC project, but this have been so hectic this year, personally and professionally, I didn't have the time to commit to hosting an intern or GSOC student this summer. :-(