On Thu, Oct 07, 2010 at 12:42:48PM -0300, Marcelo Tosatti wrote: > On Thu, Oct 07, 2010 at 12:00:13PM +0200, Avi Kivity wrote: > > On 10/06/2010 10:08 PM, Gleb Natapov wrote: > > >> Malicious userspace can cause entry to be cached, ioctl > > >> SET_USER_MEMORY_REGION 2^32 times, generation number will match, > > >> mark_page_dirty_in_slot will be called with pointer to freed memory. > > >> > > >Hmm. To zap all cached entires on overflow we need to track them. If we > > >will track then we can zap them on each slot update and drop "generation" > > >entirely. > > > > To track them you need locking. > > > > Isn't SET_USER_MEMORY_REGION so slow that calling it 2^32 times > > isn't really feasible? > > Assuming it takes 1ms, it would take 49 days. > We may fail ioctl when max value is reached. The question is how much slot changes can we expect from real guest during its lifetime. > > In any case, can use u64 generation count. > > Agree. Yes, 64 bit ought to be enough for anybody. -- Gleb. -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
