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.
