On 09.12.2014 17:36, Daniel P. Berrange wrote:
On Tue, Dec 09, 2014 at 05:29:51PM +0100, Michal Privoznik wrote:
On 09.12.2014 16:07, Daniel P. Berrange wrote:
On Tue, Dec 09, 2014 at 08:03:13AM -0700, Eric Blake wrote:
Now that Linux has a syscall for getting secure random bytes, should we
use that when available in our src/util/virrandom.c implementation?
Yes, we should. I remember reading a few weeks back that someone found
our current random seed is rather predictable when the libvirt host is
booted from a cut-down image running systemd. Since there is no longer
1000000000 lines of shell in the init process the initial PIDs are very
stable across each boot attempt.
The question is how should we make use of it ? Should we use it as the
seed for initstate_r, or just use it for virRandomBits directly ?
Well, consider that libvirt might be run in a VM with snapshot. IIUC
nowadays when the VM is started from the snapshot virRandomBits() produces
the same sequence. If we want to prevent that we must use the new syscall
every time the virRandomBits() is called. I'm afraid using the syscall just
to set the seed won't be sufficient.
If you are restoring a VM from a snapshot, the entropy pool for /dev/random
will have been preseved too, so you'll still have the same problem. This is
just one of 100's of examples of why you should never try to use snapshots
as the basis for forking multiple independant VM instances.
Correct. But after some time (and some packets, keypresses and mouse
movements too) both the syscall and the /dev/random will produce
unpredictable sequence. But that's not the case for our RNG. What I'm
saying is, if we feel that our RNG is not good enough we should use a
better one. Improving seed setting is just deferring problem. Although I
can live with Eric's approach too.
Michal
--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list