qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH for-4.1 0/7] Add qemu_getrandom and ARMv8.5-RNG


From: Richard Henderson
Subject: Re: [Qemu-devel] [PATCH for-4.1 0/7] Add qemu_getrandom and ARMv8.5-RNG
Date: Wed, 13 Mar 2019 11:35:33 -0700
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.4.0

On 3/13/19 10:57 AM, Daniel P. Berrangé wrote:
> We already have an internal API for providing strong random bytes in
> QEMU qcrypto_random_bytes. It is preferentially backed by gnutls or
> gcrypt, but if those aren't built-in it falls back to a platform
> native API like /dev/random. I've got a todo item to make that use
> getrandom on Linux/BSD when available.
> 
> I don't think we should be adding a new APIs for getting random
> numbers that aren't backed by the qcrypto_random_bytes.

That's all very well and good for one particular use case, when we really want
random numbers.  But with -seed, we want to be able to replicate one particular
execution, with fully deterministic numbers.

But certainly I can look into making the non-deterministic execution use your
existing interface.  I simply wasn't aware of it.

Do you happen to know off-hand the maximum latency of the gnutls/gcrypt
interfaces?  I do want the interface to be able to return "timed-out" in
certain cases.  With getrandom(2) there is a handy GRND_NONBLOCK parameter that
pretty much matches exactly what I want.  With /dev/{u,}random, one would have
to use O_NONBLOCK.  With BSD getentropy, I think you'd need an alarm to time
out the operation (unless EIO covers all sorts of failures like empty entropy
pool; the manual isn't clear)?


r~



reply via email to

[Prev in Thread] Current Thread [Next in Thread]