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

[Daniel P . Berrangé]

On Thu, Mar 14, 2019 at 09:06:42AM -0700, Richard Henderson wrote:
> On 3/14/19 2:54 AM, Daniel P. Berrangé wrote:
> > The random interfact is pluggable with different impls though they are
> > chosen at build time currently. I guess we could provide an impl that
> > is backed by a deterministic source and require a special CLI option or
> > env var to switch to this insecure mode at runtime.
> 
> I would think that some of the existing users of the crypto backend would not
> need an insecure switch, as they're not specifically visible to the guest.
> E.g. crypto/block-luks.c.  (Although, see below.)
> 
> What I have done, and better in the now-posted v2, is copy exactly this CLI
> option from linux-user/main.c to system mode as well.  Then, use that in only
> the places that are guest visible -- and currently use rand(3).
> 
> So, within the instances I change, I am in all cases producing better quality
> random numbers than we do currently.  In the case of -seed, using a Mersenne
> Twister algorithm instead of the rather tiny linear congruence algorithm of
> rand(3).  In the case of no -seed, by using a cryptographic quality source.
> 
> The final patch is the new ARM built-in hardware random number generation
> instruction.  The spec for the insn requires crypto quality results (complying
> to NIST...).  But, as previously stated, as a debugging tool we need to be 
> able
> to force reproduciblity.

Yes, I understand now.

> Re-checking, I now see that the uses within hw/misc/ are in fact guest visible
> emulations of hardware random number generators, and so should probably be
> switched to use my new interface, just as with the ARM instruction.

Yeah, that probably makes sense.

> 
> If you have a better name for "qemu_getrandom" that emphasizes this usage, I'm
> happy to change that.

Yep, back in your v2 thread I had suggested  qemu_cpu_getrandom, but with
your note about hw/misc, it looks a bit more general than that.  Essentially
the debugging reproducability is useful for anything that is guest facing
frontend. Where we don't want it used is in any of the backends.

So far best alternative is 'qemu_traceable_random' / tracable-random.h
but its a bit of a verbose name.


Regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|