On 03.07.2011, at 10:56, Avi Kivity wrote:

> On 07/03/2011 11:34 AM, Alexander Graf wrote:
>> >>
>> >>  Yup, which requires knowledge in the code on what actually fits :). 
>> >> Logic we don't have today.
>> >
>> >  I don't follow.  What knowledge is required?  Please give an example.
>> 
>> Sure. Let's take an easy example Currently we have for get_pvinfo:
>> 
> 
> <snip>
> 
>> The padding would not be there with your idea. An updated version could look 
>> like this:
>> 
>>         /* for KVM_PPC_GET_PVINFO */
>>         struct kvm_ppc_pvinfo {
>>                 /* out */
>>                 __u32 flags;
>>                 __u32 hcall[4];
>>                 __u64 features;  /* only there with PVINFO_FLAGS_FEATURES */
>>         };
>> 
>> Now, your idea was to not use copy_from/to_user directly, but instead some 
>> wrapper that could pad with zeros on read or truncate on write. So instead 
>> we would essentially get:
>> 
>>         int kvm_vm_ioctl_get_pvinfo(struct kvm_ppc_pvinfo *pvinfo, int 
>> *required_size)
>>         {
>>                 [...]
>>              if (pvinfo_flags&  PVINFO_FLAGS_FEATURES) {
>>                         *required_size = 16;
>>                 } else {
>>                         *required_size = 8;
>>                 }
>>                 [...]
>>         }
> 
> 
> Why?  Kernel code would only consider the full structure.
> 
> 
>>         case KVM_PPC_GET_PVINFO: {
>>                 struct kvm_ppc_pvinfo pvinfo;
>>                 int required_size = 0;
>>                 memset(&pvinfo, 0, sizeof(pvinfo));
>>                 r = kvm_vm_ioctl_get_pvinfo(&pvinfo,&required_size);
>>                 if (copy_to_user(argp,&pvinfo, required_size) {
>>                         r = -EFAULT;
>>                         goto out;
>>                 }
> 
> required_size would come from the size encoded in the ioctl number, no need 
> to calculate it separately.
> 
>>                 break;
>>         }
>> 
>> 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 :).


Alex

_______________________________________________
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Reply via email to