All of lore.kernel.org
 help / color / mirror / Atom feed
From: Thomas Huth <thuth@redhat.com>
To: Nikunj A Dadhania <nikunj@linux.vnet.ibm.com>,
	David Gibson <david@gibson.dropbear.id.au>
Cc: Ravi Bangoria <ravi.bangoria@linux.vnet.ibm.com>,
	qemu-ppc@nongnu.org, qemu-devel@nongnu.org, rth@twiddle.net,
	Amit Shah <amit.shah@redhat.com>
Subject: Re: [Qemu-devel] [Qemu-ppc] [PATCH 2/6] target-ppc: Implement darn instruction
Date: Fri, 12 Aug 2016 11:29:17 +0200	[thread overview]
Message-ID: <9a33f3e4-65cb-6546-a50b-a4b3716dae01@redhat.com> (raw)
In-Reply-To: <87bn0yjs5k.fsf@abhimanyu.i-did-not-set--mail-host-address--so-tickle-me>

On 12.08.2016 10:41, Nikunj A Dadhania wrote:
> Thomas Huth <thuth@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!

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.

 Thomas

  reply	other threads:[~2016-08-12 14:18 UTC|newest]

Thread overview: 42+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-08-07 17:36 [Qemu-devel] [PATCH 0/6] POWER9 TCG enablements - part4 Nikunj A Dadhania
2016-08-07 17:36 ` [Qemu-devel] [PATCH 1/6] target-ppc: add xxspltib instruction Nikunj A Dadhania
2016-08-08  4:43   ` Richard Henderson
2016-08-08  6:19     ` Nikunj A Dadhania
2016-08-07 17:36 ` [Qemu-devel] [PATCH 2/6] target-ppc: Implement darn instruction Nikunj A Dadhania
2016-08-07 21:33   ` Benjamin Herrenschmidt
2016-08-08  1:52     ` Nikunj A Dadhania
2016-08-08  3:22       ` Benjamin Herrenschmidt
2016-08-08  3:32         ` Nikunj A Dadhania
2016-08-09  3:28     ` David Gibson
2016-08-09  4:54       ` Nikunj A Dadhania
2016-08-09  9:17         ` [Qemu-devel] [Qemu-ppc] " Nikunj A Dadhania
2016-08-12  6:29           ` David Gibson
2016-08-12  6:43             ` Nikunj A Dadhania
2016-08-12  6:56               ` David Gibson
2016-08-12  7:13                 ` Nikunj A Dadhania
2016-08-12  7:29               ` Thomas Huth
2016-08-12  7:39                 ` Nikunj A Dadhania
2016-08-12  7:55                   ` Thomas Huth
2016-08-12  8:41                     ` Nikunj A Dadhania
2016-08-12  9:29                       ` Thomas Huth [this message]
2016-08-12  9:51                         ` Nikunj A Dadhania
2016-08-12 13:26                           ` Richard Henderson
2016-08-12 13:39                             ` Nikunj A Dadhania
2016-08-15 10:28                         ` David Gibson
2016-08-08  5:01   ` [Qemu-devel] " Richard Henderson
2016-08-08  6:20     ` Nikunj A Dadhania
2016-08-07 17:36 ` [Qemu-devel] [PATCH 3/6] target-ppc: add lxsi[bw]zx instruction Nikunj A Dadhania
2016-08-08  5:08   ` Richard Henderson
2016-08-08  6:21     ` Nikunj A Dadhania
2016-08-07 17:36 ` [Qemu-devel] [PATCH 4/6] target-ppc: add stxsi[bh]x instruction Nikunj A Dadhania
2016-08-08  5:08   ` Richard Henderson
2016-08-07 17:36 ` [Qemu-devel] [PATCH 5/6] target-ppc: add lxvb16x and lxvh8x Nikunj A Dadhania
2016-08-08  5:27   ` Richard Henderson
2016-08-08  6:35     ` Richard Henderson
2016-08-10  9:21       ` Nikunj A Dadhania
2016-08-10 10:12         ` Richard Henderson
2016-08-10 10:33           ` Nikunj A Dadhania
2016-08-10 15:21           ` Nikunj A Dadhania
2016-08-07 17:36 ` [Qemu-devel] [PATCH 6/6] target-ppc: add stxvb16x and stxvh8x Nikunj A Dadhania
2016-08-08  5:27   ` Richard Henderson
2016-08-09  3:30 ` [Qemu-devel] [PATCH 0/6] POWER9 TCG enablements - part4 David Gibson

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=9a33f3e4-65cb-6546-a50b-a4b3716dae01@redhat.com \
    --to=thuth@redhat.com \
    --cc=amit.shah@redhat.com \
    --cc=david@gibson.dropbear.id.au \
    --cc=nikunj@linux.vnet.ibm.com \
    --cc=qemu-devel@nongnu.org \
    --cc=qemu-ppc@nongnu.org \
    --cc=ravi.bangoria@linux.vnet.ibm.com \
    --cc=rth@twiddle.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.