Re: [Qemu-ppc] [Qemu-devel] [PATCH 2/6] target-ppc: Implement darn instruction

[David Gibson]

On Fri, Aug 12, 2016 at 11:29:17AM +0200, Thomas Huth wrote:
> On 12.08.2016 10:41, Nikunj A Dadhania wrote:
> > Thomas Huth <address@hidden> 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!
> 
> 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.
> 
> > 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!
> 
> >> 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.
> 
> 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
> (might be some work to get this running on Windows and Mac OS X, too).
> 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.

So, a couple of options we have here.  The error condition option for
the instruction helps a fair bit.

Option 1 is to to have helper_darn() wait for a short timeout to get
random data, if it doesn't get something in time, return an error.

To reduce the latency further, you could have a one word buffer with
the next random number.  A background thread would attempt to refill
that from the rng backend.  darn would return the number in the
buffer, or an error if it hasn't been filled yet.  This implementation
could be reasonably done without a helper, I think, which might be an
advantage.

Unless there's some clever solution that x86 have already come up with
for rdrand in linux-user, I think we want to find some way to
construct the rng backend there as well.  Falling back to a different
rng for user only seems very risky to me.

-- 
David Gibson                    | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au  | minimalist, thank you.  NOT _the_ _other_
                                | _way_ _around_!
http://www.ozlabs.org/~dgibson

signature.asc
Description: PGP signature