Creating more entropy for a Linux kernel in a virtualized environment

So far my research has turned up a few solutions though none that I consider to be that great. I’ve also learned that both Xen and VMware seem to have this problem and it would not surprise if other virtualization solutions do as well. The root of the problem is actually that the Linux kernel relies heavily on interrupts for generating random numbers. In a virtualized environment a Linux kernel will be unable to generate random numbers due to being unable to access the hardware. The solution would probably be for the virtualization software to emulate a hardware random number generator that gets random data from the host system. That’s assuming that the Linux kernel isn’t adjusted in some way to account for this issue.

However, I wouldn’t expect either the Linux kernel or virtualization products to change anytime soon. So in the meantime here are some solutions that people have tried.

Make /dev/random an alias for /dev/urandom

This can be done by removing /dev/random and either using a symlink or using the mknod command. I’m not going to list the steps because I feel this is not the best solution.

Using rng-tools to increase entropy

At worst this solution is no better and no worse than the one above but at best it might be somewhat better.

• sudo apt-get install rng-tools
• nano /etc/default/rng-tools
• add the line: HRNGDEVICE=/dev/urandom
• /etc/init.d/rng-tools start

This sets up the rngd process to write date from /dev/urandom to /dev/random. Again, this may not improve the quality of the random numbers from /dev/random but it should be at least as good as /dev/urandom. This is also a great quick fix for services that are failing due to lack of entropy. While a person may not want to rely on the strength of this encryption for financial or other sensitive data, it may be fine for a number of purposes.

Update: I also found that in order to have entropy when needed on boot (say before the cryptdisks and cryptdisks-early scripts) I had to start the rngd daemon much earlier. The following command can accomplish this (yes the period at the end is needed): update-rc.d -n rng-tools start 25 S .

Getting random data from the web

In my research I came across the Debian/Ubuntu package “reseed” which downloads data from http://random.org to seed /dev/urandom. I would strongly recommend against using this package since it receives the random data in plaintext. However, it raised the idea of receiving random data from the internet. I did some checking on http://random.org and found that one can get random numbers via ssl. The question is, should one do so? I think there are 2 trust issues in this case: 1) Do you trust that the numbers from http://random.org are truly random? 2) Do you trust that http://random.org will not track the random numbers being sent to a computer’s ip address? A third question would be: What is the likelihood of a third party circumventing the ssl encryption http://random.org to record the random numbers?

However this email concerning entropy in the Linux kernel suggests that writing any data to /dev/random should be fine even if an attacker knows the data. Additionally this is not the sole source of entropy for the kernel but rather an additional source. I’ve been thinking of a script that sits in /etc/cron.hourly/ that will read some random data from http://random.org and write it to /dev/random. There’s a practical limit of 200,000 bits per day from http://random.org per ip. So 10 virtual servers requesting 512 bits (64 bytes) of entropy per hour would require 122,880 bits per day. An additional benefit is that an attacker who knows the random data still would not know which virtual server received that particular data set.

Why not a hardware random number generator?

One solution that I’ve seen suggested is purchasing a hardware rng. Unfortunately this will not help except in 1 instance. If you have only 1 virtual server that needs strong cryptography you could purchase a hardware rng and allow just that 1 virtual server to access it. Otherwise, adding a hardware rng to the host system only exacerbates the problem as the host will have even more entropy readily available without a means of feeding it to the guests.