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

[Michal Privoznik]

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