On Thursday 11 May 2006 09:49, Keir Fraser wrote:
> On 11 May 2006, at 01:33, Herbert Xu wrote:
> >> But if sampling virtual events for randomness is really unsafe (is it
> >> really?) then native guests in Xen would also get bad random numbers
> >> and this would need to be somehow addressed.
> >
> > Good point. I wonder what VMWare does in this situation.
>
> Well, there's not much they can do except maybe jitter interrupt
> delivery. I doubt they do that though.
>
> The original complaint in our case was that we take entropy from
> interrupts caused by other local VMs, as well as external sources.
> There was a feeling that the former was more predictable and could form
> the basis of an attack. I have to say I'm unconvinced: I don't really
> see that it's significantly easier to inject precisely-timed interrupts
> into a local VM. Certainly not to better than +/- a few microseconds.
> As long as you add cycle-counter info to the entropy pool, the least
> significant bits of that will always be noise.
I think I agree - e.g. i would expect the virtual interrupts to have
enough jitter too. Maybe it would be good if someone could
run a few statistics on the resulting numbers?
Ok the randomness added doesn't consist only of the least significant
bits. Currently it adds jiffies+full 32bit cycle count. I guess if it was
a real problem the code could be changed to leave out the jiffies and 
only add maybe a 8 bit word from the low bits. But that would only
help for the para case because the algorithm for native guests
cannot be changed.
> 2. An entropy front/back is tricky -- how do we decide how much
> entropy to pull from domain0? How much should domain0 be prepared to
> give other domains? How easy is it to DoS domain0 by draining its
> entropy pool? Yuk.
I claim (without having read any code) that in theory you need to have solved 
that problem already in the vTPM @)
-Andi
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel