Thor Lancelot Simon <tls%panix.com@localhost> writes: > On Fri, Feb 24, 2012 at 08:56:44AM -0500, Greg Troxel wrote: >> >> > What's wrong with xbd? >> >> I think what might be wrong with xbd is that another domU could observe >> things that are correlated in time with the transactions on this domU, >> and thereby predict other domUs entropy values. > > What are those things, exactly? Changes in the latency of its own disk > requests? Yes. Basically, I suspect that all the latencies are correlated, because they are (in the typical case) being served off the same underlying storage. So knowing all of one's own xbd timing data seems likely to enable some prediction of the timing of other domU's xbd events. And once one domU has any information about the inputs to another domU's RNG, it seems like time to worry. This is really the same argument why use of network devices to estimate randomness is scary. The same goes for xennet. But, given a RNG framework that hashes everything, you could argue that even significant prediction will lead to nothing, and it seems in -6 we're in a post-estimation world. I haven't fully grasped that yet, but should. The right thing would seem to be to run a good crypto PRNG in either xen proper or the dom0, and to be able to pull bits from that to seed a crypto PRNG in the domU, using a new 'get random bits' hypercall. Or, some bits from a hardware RNG could be diverted to domUs via this hypercall. I am having negative spare time, but this seems doable in only a few days of hacking.
Attachment:
pgpYcjwOJR0c_.pgp
Description: PGP signature