Re: [Qemu-devel] [PATCH v3 0/1] virtio-rng: hardware random number generator

[H. Peter Anvin]

On 09/16/2012 04:23 PM, Anthony Liguori wrote:
> This is *exactly* what the problem is.
>
> If using /dev/urandom is pointless--and so far, many people have made
> compelling arguments that it is--then using /dev/random is seemingly
> impossible to do fairly.

It is not merely pointless, it is a security hole.

> The virtio-rng interface doesn't have any notion of guarantee of entropy
> availability.  The guest just keeps requesting entropy with no
> indication to the hypervisor of what it should and shouldn't give.

With the latest fixes to rngd this is no longer true.  This *was* a bug 
in rngd < 4; it would always claim to be entropy-starved (and so a guest 
running rngd < 4 will have this pathology, but no distro is known to run 
rngd < 4 by default due to a number of other problems with these 
versions of rngd).  This has been fixed.  If that backpressure isn't 
propagated through the virtio-rng driver then that does need to be 
fixed, but from at least a cursory look I think it does.

> Since /dev/random is a finite pool, it's quite possible that one guest
> could quickly exhaust /dev/random for all other guests.  How is this not
> a clear denial of service?

Well, by that definition the fact that the service hasn't been provided 
at all until now is a bigger denial of service...

> This is why supporting EGD is so important IMHO.  Something else needs
> to deal with handing out entropy in a responsible way.

No, you're missing the key point.  Fixing this in applications (and from 
the host kernel's perspective, this is an application) is broken, 
because it is not just Qemu that has that property.  If this is an 
actual problem (and it's not clear to me that it is in anything but 
theory, because although the kernel doesn't do round robin it will at 
least provide amount of stochastic fairness) then it is in the kernel 
that the fix belongs.

Throwing an extra daemon -- one which doesn't even claim to be designed 
for this purpose -- into the middle is just silly.  Either which way, it 
can easily be handled via a sane fairness daemon which doesn't need a 
complicated protocol.

> Anyway, this is on my list for 1.3.  The series just needs some light
> dusting before resubmission.

        -hpa

--
H. Peter Anvin, Intel Open Source Technology Center
I work for Intel.  I don't speak on their behalf.