Re: [RFC PATCH 17/17] KVM: PPC: Add an ioctl for userspace to select which platform to emulate

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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.

--
error compiling committee.c: too many arguments to function

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


[Index of Archives]     [KVM ARM]     [KVM ia64]     [KVM ppc]     [Virtualization Tools]     [Spice Development]     [Libvirt]     [Libvirt Users]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite Questions]     [Linux Kernel]     [Linux SCSI]     [XFree86]
  Powered by Linux