Thomas Huth <th...@redhat.com> writes:
>>> You can not rely on /dev/random for this job, since it might block. So
>>> your guest would stop executing when there is not enough random data
>>> available in the host, and I think that's quite a bad behavior...
>>
>> Hmm.. rng-random does use this, but it might have way to time out probably:
>>
>> backends/rng-random.c: s->filename = g_strdup("/dev/random");
>
> This is only the default value, which is likely suitable for
> virtio-rng,
Right, we will need to find maybe an algorithm that can give us
sufficient distribution, or use random() with time-of-day and get some
function.
MIPS does have some thing in cpu_mips_get_random(). Its for 32-bit,
probably can be extended to 64-bit. Mathematically, I am not sure. :-)
> but not for something like this instruction (or the H_RANDOM hypercall).
> You can set the filename property to another file when instantiating it,
> like:
>
> qemu-system-xxx ... -object rng-random,filename=/dev/hwrng,id=rng0 ...
>
> That's the whole point these backends - you give the users the
> possibility to chose the right source of entropy.
>
> For example, on the POWER8 machine that I have here, /dev/random blocks
> after a couple of bytes, you can see that easily by typing something
> like "hexdump /dev/random". It only delivers more random data when I run
> "rngd -r /dev/hwrng" in the background.
Regards,
Nikunj
