On 03.07.2011, at 11:05, Avi Kivity wrote:

On 07/03/2011 12:00 PM, Alexander Graf wrote:

quoted

quoted

quoted

         }

 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.

quoted

quoted

 I don't see why we have to caclulate something, then verify it =

against the correct answer.

quoted

=20
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 =
:).

quoted

=20

=20
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