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, send a message with 'unsubscribe linux-mm' in the body to majordomo@xxxxxxxxxx For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>