On 03.07.2011, at 11:05, Avi Kivity wrote: > On 07/03/2011 12:00 PM, Alexander Graf wrote: >> >> } >> >> >> >> Otherwise we might write over data the user expected. And that logic that tells to copy_to_user how much data it actually takes to put all the information in is not there today and would have to be added. You can even verify that required_size with the ioctl passed size to make 100% sure user space is sane, but I'd claim that a feature bitmap is plenty of information to ensure that we're not doing something stupid. >> > >> > I don't see why we have to caclulate something, then verify it against the correct answer. >> >> Ah, I think I'm grasping your idea. You'd simply truncate the resulting struct according to the size passed by the ioctl and call it a day. Well, that works too. User space simply wouldn't be able to know if all information actually fit into the struct, but I guess that's fine :). >> > > Right. The idea is that if KVM_FLAG_BLAH implies a field kvm_struct::blah, then either both are present in the headers, or none of them. Yup, makes sense. I like the idea :). Gets rid of all the useless paddings and reserved fields. We could even truncate the structs that already have paddings in them if we only copy min(sizeof(real_struct), ioctl_passed_size); (which we should anyways). How long until we get a patch set? :) Alex -- 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
