[libvirt] should we use new Linux syscall getrandom(2)?

Eric Blake eblake at redhat.com
Tue Dec 9 15:17:24 UTC 2014


On 12/09/2014 08:07 AM, Daniel P. Berrange wrote:
> On Tue, Dec 09, 2014 at 08:03:13AM -0700, Eric Blake wrote:
>> Now that Linux has a syscall for getting secure random bytes, should we
>> use that when available in our src/util/virrandom.c implementation?
> 
> Yes, we should. I remember reading a few weeks back that someone found
> our current random seed is rather predictable when the libvirt host is
> booted from a cut-down image running systemd. Since there is no longer
> 1000000000 lines of shell in the init process the initial PIDs are very
> stable across each boot attempt.
> 
> The question is how should we make use of it ?  Should we use it as the
> seed for initstate_r, or just use it for virRandomBits directly ?

I think using it just to set the seed is sufficient - I don't know if
using ALL our random bits from the syscall would drain resources that
might starve other processes, and we are leaving the crypto code to
libraries that probably have their own rules on how they get their
random values secure enough for their needs.  So minimizing our use to
just the seeding process will play nicer with other processes, give us
less predictability at startup, and still be something that we can
easily override during debugging to get a fixed random sequence if it is
ever needed (we have some #if code that is normally off, but can be
turned on to generated a repeatable sequence from a fixed seed; using
the syscall all the time would defeat that if we ever hit a situation of
needing fixed-sequence debugging).

-- 
Eric Blake   eblake redhat com    +1-919-301-3266
Libvirt virtualization library http://libvirt.org

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 539 bytes
Desc: OpenPGP digital signature
URL: <http://listman.redhat.com/archives/libvir-list/attachments/20141209/08124af7/attachment-0001.sig>


More information about the libvir-list mailing list