[Top][All Lists]

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

Re: [Qemu-devel] RFC: virtio-rng and /dev/urandom

From: H. Peter Anvin
Subject: Re: [Qemu-devel] RFC: virtio-rng and /dev/urandom
Date: Sun, 17 Apr 2016 17:27:05 -0700
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.7.1

On 04/16/16 01:31, Paolo Bonzini wrote:
> Right, but there's always the point about people that use heterogeneous
> hosts and cannot pass rdrand/rdseed to the guest.  For these, we should
> add a QEMU driver that uses rdrand/rdseed, and thus decouples virtio-rng
> from the host /dev/* completely.
> From the libvirt POV there are various possibilities:
> - Libvirt can have a libvirt.conf parameter that says "ignore whatever is
> specified in the guest XML if rdrand/rdseed is available, and instead use
> rdrand/rdseed".
> - Libvirt can allow specifying rdrand/rdseed _and_ an additional backend,
> like this:
>     <backend model="cpu"/>
>     <backend model="random">/dev/random</backend>
> and fallback to the second if rdrand/rdseed are not available.

The other thing, and this is one area where there is some legitimacy to
the /dev/urandom argument: on a fresh boot, it would be highly desirable
to get a seed value from virtio-rng even if that is "entropyless".  The
backwards-compatible way would be to provide, say, 64 bytes of
/dev/urandom before switching to /dev/random, but it might be desirable
to give the guest OS some way to cause that to reset, explicitly
requesting a new seed after an in-VM guest reboot, kexec et al.

This also ties into the proposed MSR to support kASLR in the guest in
the absence of rdrand/rdseed.  Using virtio in that phase of bootup is
generally not feasible.


reply via email to

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