Re: [libvirt] should we use new Linux syscall getrandom(2)?

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.