Thomas Huth <th...@redhat.com> writes:
> On 12.08.2016 10:41, Nikunj A Dadhania wrote:
>> 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.
>
> First, hands off rand() and random()! These are certainly not suited for
> implementing an opcode that is likely thought to deliver
> cryptographically suitable random data!
Sure :-)
> This topic is really not that easy, I had the same problems also when
> thinking about the implementation of H_RANDOM. You need a source that
> gives you cryptographically suitable data, you've got to make sure that
> your algorithm does not block the guest, and you've got to do it in a
> somewhat system-independent manner (i.e. QEMU should still run on
> Windows and Mac OS X afterwards). That's why I came to the conclusion
> that it's best to use the rng backends for this job when implementing
> the H_RANDOM stuff, and let the users decide which source is best suited
> on their system.
Right, that was the first attempt, as we need to cater to linux-user as
well, that does not have bells and whistles of system. Many
functionality missing, right from the rng-backend isnt part of the
linux-user emulator.
>> 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. :-)
>
> That's certainly not an algorithm which is suitable for crypto data!
Thanks for confirming.
>>> 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.
>
> Of course this is getting ugly here, since a CPU instruction is not as
> optional as the H_RANDOM hypercall for example.
> So I basically see to ways to follow here:
>
> 1) Implement it similar to the H_RANDOM hypercall, i.e. make it optional
> and let the user decide the right source of entropy with a "-object
> rng-random" backend. If such a backend has not been given on the command
> line, let the "darn" instruction simply always return 0xFFFFFFFFFFFFFFFF
> to signal an error condition - the guest is then forced to use another
> way to get random data instead.
We might need to differentiate between linux-user and system maybe to
use the rng backend.
> 2) Try to introduce a generic get_crypto_random_data() function to QEMU
> that can be called to get cryptographically suitable random data in any
> case. The function then should probe for /dev/random, /dev/hwrng or
> other suitable sources on its own when being called for the first time
Yes, I can try that.
> (might be some work to get this running on Windows and Mac OS X, too).
I am not to sure about this. Would need some help.
> You then still have to deal with a blocking /dev/random device, though,
> so maybe the data with the good entropy should not be returned directly
> but rather used to seed a good deterministic RNG instead, like the one
> from the glib (have a look at the g_rand_int() function and friends).
> Anyway, someone with a good knowledge of crypto stuff should review such
> an implementation first before we include that, I think.
I can drop this from my patch series, until we have clarity here.
Regards
Nikunj
