4 ms·

Regardless, whether it be OpenSSL first or /dev/urandom first, "haveged" entropy generation is still needed for virtual machines, which is the most common use c

Regardless, whether it be OpenSSL first or /dev/urandom first, "haveged" entropy generation is still needed for virtual machines, which is the most common use case. In my experience both ways are a no-go without special measures like haveged being put in place to super-charge the available entropy. I've had processes hang up for MINUTES or just under TWO HOURS waiting for more entropy to be available.

tptacek 10y ago
No, it's not. Don't use haveged. Virtual machines should simply get their initial entropy from the already-seeded urandom pool of their hypervisor host. Processes don't "hang waiting for more entropy"; they hang because /dev/random inexplicably goes on strike. The answer to that problem is "never use /dev/random".
- matt_wulfeck 10y ago
  true but even if we don't want to use /dev/random, there's still software using it all over the place that we don't necessarily want to patch. I end up installing haveged just because I don't want the system mysteriously locking up because some random daemon wants to create a 4096 bit key on first startup.
  - viraptor 10y ago
    Replacing random with urandom for one app is just one LD_PRELOAD away. Similar to https://rafalcieslak.wordpress.com/2013/04/02/dynamic-linker-tricks-using-ld_preload-to-cheat-inject-features-and-investigate-programs/ https://rafalcieslak.wordpress.com/2013/04/02/dynamic-linker... you can replace open("/dev/random") with open("/dev/urandom")
    - throwaway2048 10y ago
      Its much easier and less error prone to just replace the device node.
      - viraptor 10y ago
        I'd rather go for a limited scope. But yes, one way or another, you don't have to suffer just because someone hardcoded /dev/random in the app.
viraptor 10y ago
That's one of the solutions, but not the only one. QEMU's solution is another virtio device: http://wiki.qemu.org/Features-Done/VirtIORNG http://wiki.qemu.org/Features-Done/VirtIORNG I expect XEN and others to follow soon. Also RDRAND can be executed in a VM, but I'm not sure if it is handled properly yet. And like tptacek mentioned - why did you use blocking random in the app?
- matt_wulfeck 10y ago
  Actually it's still kind of an issue. The qemu virtio device reads only from the hosts /dev/random device (not urandom) so you can still starve the hypervisor. Also the guest -- even though is properly seeded -- can entropy starve because who knows what is installed on it. And clearly there's still confusion about using /dev/random. I don't even think the solution is to point everything to /dev/urandom. Why maintain two? Why constantly have to explain to people the difference? The BSD developers merged both devices into /dev/urandom and I think that's the right approach.
  - viraptor 10y ago
    It's configurable. You can even forward host's /dev/urandom as guest's /dev/random.
    - matt_wulfeck 10y ago
      Actually it's not supported with virtio-rng. Here[0] is a proposed patch to add support. [0] http://www.redhat.com/archives/libvir-list/2016-March/msg01062.html http://www.redhat.com/archives/libvir-list/2016-March/msg010...
      - viraptor 10y ago
        I knew you can change the source (it accepts egd after all), but didn't know they actually prevent you from choosing urandom. This is sad :(
- mioelnir 10y ago

tptacek 10y ago

No, it's not. Don't use haveged. Virtual machines should simply get their initial entropy from the already-seeded urandom pool of their hypervisor host. Processes don't "hang waiting for more entropy"; they hang because /dev/random inexplicably goes on strike. The answer to that problem is "never use /dev/random".

matt_wulfeck 10y ago
true but even if we don't want to use /dev/random, there's still software using it all over the place that we don't necessarily want to patch. I end up installing haveged just because I don't want the system mysteriously locking up because some random daemon wants to create a 4096 bit key on first startup.
- viraptor 10y ago
  Replacing random with urandom for one app is just one LD_PRELOAD away. Similar to https://rafalcieslak.wordpress.com/2013/04/02/dynamic-linker-tricks-using-ld_preload-to-cheat-inject-features-and-investigate-programs/ https://rafalcieslak.wordpress.com/2013/04/02/dynamic-linker... you can replace open("/dev/random") with open("/dev/urandom")
  - throwaway2048 10y ago
    Its much easier and less error prone to just replace the device node.
    - viraptor 10y ago
      I'd rather go for a limited scope. But yes, one way or another, you don't have to suffer just because someone hardcoded /dev/random in the app.

viraptor 10y ago

That's one of the solutions, but not the only one. QEMU's solution is another virtio device: http://wiki.qemu.org/Features-Done/VirtIORNG http://wiki.qemu.org/Features-Done/VirtIORNG I expect XEN and others to follow soon. Also RDRAND can be executed in a VM, but I'm not sure if it is handled properly yet. And like tptacek mentioned - why did you use blocking random in the app?

matt_wulfeck 10y ago
Actually it's still kind of an issue. The qemu virtio device reads only from the hosts /dev/random device (not urandom) so you can still starve the hypervisor. Also the guest -- even though is properly seeded -- can entropy starve because who knows what is installed on it. And clearly there's still confusion about using /dev/random. I don't even think the solution is to point everything to /dev/urandom. Why maintain two? Why constantly have to explain to people the difference? The BSD developers merged both devices into /dev/urandom and I think that's the right approach.
- viraptor 10y ago
  It's configurable. You can even forward host's /dev/urandom as guest's /dev/random.
  - matt_wulfeck 10y ago
    Actually it's not supported with virtio-rng. Here[0] is a proposed patch to add support. [0] http://www.redhat.com/archives/libvir-list/2016-March/msg01062.html http://www.redhat.com/archives/libvir-list/2016-March/msg010...
    - viraptor 10y ago
      I knew you can change the source (it accepts egd after all), but didn't know they actually prevent you from choosing urandom. This is sad :(
mioelnir 10y ago