From: Jike Song <jike.song@intel.com> To: Kirti Wankhede <kwankhede@nvidia.com> Cc: Dong Jia <bjsdjshi@linux.vnet.ibm.com>, alex.williamson@redhat.com, pbonzini@redhat.com, kraxel@redhat.com, cjia@nvidia.com, qemu-devel@nongnu.org, kvm@vger.kernel.org, kevin.tian@intel.com Subject: Re: [PATCH v7 2/4] vfio: VFIO driver for mediated devices Date: Thu, 08 Sep 2016 10:38:00 +0800 [thread overview] Message-ID: <57D0CF08.6020106@intel.com> (raw) In-Reply-To: <72e3baa7-70d1-c5dd-6cd7-3874e7ea4c01@nvidia.com> On 08/26/2016 10:13 PM, Kirti Wankhede wrote: > > > On 8/25/2016 2:52 PM, Dong Jia wrote: >> On Thu, 25 Aug 2016 09:23:53 +0530 >> Kirti Wankhede <kwankhede@nvidia.com> wrote: >> >> [...] >> >> Dear Kirti, >> >> I just rebased my vfio-ccw patches to this series. >> With a little fix, which was pointed it out in my reply to the #3 >> patch, it works fine. >> > > Thanks for update. Glad to know this works for you. > > >>> +static long vfio_mdev_unlocked_ioctl(void *device_data, >>> + unsigned int cmd, unsigned long arg) >>> +{ >>> + int ret = 0; >>> + struct vfio_mdev *vmdev = device_data; >>> + struct parent_device *parent = vmdev->mdev->parent; >>> + unsigned long minsz; >>> + >>> + switch (cmd) { >>> + case VFIO_DEVICE_GET_INFO: >>> + { >>> + struct vfio_device_info info; >>> + >>> + minsz = offsetofend(struct vfio_device_info, num_irqs); >>> + >>> + if (copy_from_user(&info, (void __user *)arg, minsz)) >>> + return -EFAULT; >>> + >>> + if (info.argsz < minsz) >>> + return -EINVAL; >>> + >>> + if (parent->ops->get_device_info) >>> + ret = parent->ops->get_device_info(vmdev->mdev, &info); >>> + else >>> + return -EINVAL; >>> + >>> + if (ret) >>> + return ret; >>> + >>> + if (parent->ops->reset) >>> + info.flags |= VFIO_DEVICE_FLAGS_RESET; >> Shouldn't this be done inside the get_device_info callback? >> > > I would like Vendor driver to set device type only. Reset flag should be > set on basis of reset() callback provided. > >>> + >>> + memcpy(&vmdev->dev_info, &info, sizeof(info)); >>> + >>> + return copy_to_user((void __user *)arg, &info, minsz); >>> + } >> [...] >> >>> + >>> +static ssize_t vfio_mdev_read(void *device_data, char __user *buf, >>> + size_t count, loff_t *ppos) >>> +{ >>> + struct vfio_mdev *vmdev = device_data; >>> + struct mdev_device *mdev = vmdev->mdev; >>> + struct parent_device *parent = mdev->parent; >>> + unsigned int done = 0; >>> + int ret; >>> + >>> + if (!parent->ops->read) >>> + return -EINVAL; >>> + >>> + while (count) { >> Here, I have to say sorry to you guys for that I didn't notice the >> bad impact of this change to my patches during the v6 discussion. >> >> For vfio-ccw, I introduced an I/O region to input/output I/O >> instruction parameters and results for Qemu. The @count of these data >> currently is 140. So supporting arbitrary lengths in one shot here, and >> also in vfio_mdev_write, seems the better option for this case. >> >> I believe that if the pci drivers want to iterate in a 4 bytes step, you >> can do that in the parent read/write callbacks instead. >> >> What do you think? >> > > I would like to know Alex's thought on this. He raised concern with this > approach in v6 reviews: > "But I think this is exploitable, it lets the user make the kernel > allocate an arbitrarily sized buffer." It is impossible to check count here, because one simply doesn't have the knowledge of this region. VFIO_DEVICE_GET_REGION_INFO was implemented in vfio-mdev.ko, while decoding the vfio_mdev_read to a particular MMIO region was expected to be implemented in vendor driver, that results in unbalanced interfaces. To have balanced interfaces, you either: - call ioctl instead of GET_REGION_INFO - call read instead of decoding REGION or: - call GET_REGION_INFO instead of ioctl - decode REGION in read, and check its validity, call region-specific read function V6 was the latter, v7 is kind of a mixture of these two, while I believe the former will completely address such problem :) -- Thanks, Jike >>> + size_t filled; >>> + >>> + if (count >= 4 && !(*ppos % 4)) { >>> + u32 val; >>> + >>> + ret = parent->ops->read(mdev, (char *)&val, sizeof(val), >>> + *ppos); >>> + if (ret <= 0) >>> + goto read_err; >>> + >>> + if (copy_to_user(buf, &val, sizeof(val))) >>> + goto read_err; >>> + >>> + filled = 4; >>> + } else if (count >= 2 && !(*ppos % 2)) { >>> + u16 val; >>> + >>> + ret = parent->ops->read(mdev, (char *)&val, sizeof(val), >>> + *ppos); >>> + if (ret <= 0) >>> + goto read_err; >>> + >>> + if (copy_to_user(buf, &val, sizeof(val))) >>> + goto read_err; >>> + >>> + filled = 2; >>> + } else { >>> + u8 val; >>> + >>> + ret = parent->ops->read(mdev, &val, sizeof(val), *ppos); >>> + if (ret <= 0) >>> + goto read_err; >>> + >>> + if (copy_to_user(buf, &val, sizeof(val))) >>> + goto read_err; >>> + >>> + filled = 1; >>> + } >>> + >>> + count -= filled; >>> + done += filled; >>> + *ppos += filled; >>> + buf += filled; >>> + } >>> + >>> + return done; >>> + >>> +read_err: >>> + return -EFAULT; >>> +} >> [...] >> >> -------- >> Dong Jia >>
WARNING: multiple messages have this Message-ID (diff)
From: Jike Song <jike.song@intel.com> To: Kirti Wankhede <kwankhede@nvidia.com> Cc: Dong Jia <bjsdjshi@linux.vnet.ibm.com>, alex.williamson@redhat.com, pbonzini@redhat.com, kraxel@redhat.com, cjia@nvidia.com, qemu-devel@nongnu.org, kvm@vger.kernel.org, kevin.tian@intel.com Subject: Re: [Qemu-devel] [PATCH v7 2/4] vfio: VFIO driver for mediated devices Date: Thu, 08 Sep 2016 10:38:00 +0800 [thread overview] Message-ID: <57D0CF08.6020106@intel.com> (raw) In-Reply-To: <72e3baa7-70d1-c5dd-6cd7-3874e7ea4c01@nvidia.com> On 08/26/2016 10:13 PM, Kirti Wankhede wrote: > > > On 8/25/2016 2:52 PM, Dong Jia wrote: >> On Thu, 25 Aug 2016 09:23:53 +0530 >> Kirti Wankhede <kwankhede@nvidia.com> wrote: >> >> [...] >> >> Dear Kirti, >> >> I just rebased my vfio-ccw patches to this series. >> With a little fix, which was pointed it out in my reply to the #3 >> patch, it works fine. >> > > Thanks for update. Glad to know this works for you. > > >>> +static long vfio_mdev_unlocked_ioctl(void *device_data, >>> + unsigned int cmd, unsigned long arg) >>> +{ >>> + int ret = 0; >>> + struct vfio_mdev *vmdev = device_data; >>> + struct parent_device *parent = vmdev->mdev->parent; >>> + unsigned long minsz; >>> + >>> + switch (cmd) { >>> + case VFIO_DEVICE_GET_INFO: >>> + { >>> + struct vfio_device_info info; >>> + >>> + minsz = offsetofend(struct vfio_device_info, num_irqs); >>> + >>> + if (copy_from_user(&info, (void __user *)arg, minsz)) >>> + return -EFAULT; >>> + >>> + if (info.argsz < minsz) >>> + return -EINVAL; >>> + >>> + if (parent->ops->get_device_info) >>> + ret = parent->ops->get_device_info(vmdev->mdev, &info); >>> + else >>> + return -EINVAL; >>> + >>> + if (ret) >>> + return ret; >>> + >>> + if (parent->ops->reset) >>> + info.flags |= VFIO_DEVICE_FLAGS_RESET; >> Shouldn't this be done inside the get_device_info callback? >> > > I would like Vendor driver to set device type only. Reset flag should be > set on basis of reset() callback provided. > >>> + >>> + memcpy(&vmdev->dev_info, &info, sizeof(info)); >>> + >>> + return copy_to_user((void __user *)arg, &info, minsz); >>> + } >> [...] >> >>> + >>> +static ssize_t vfio_mdev_read(void *device_data, char __user *buf, >>> + size_t count, loff_t *ppos) >>> +{ >>> + struct vfio_mdev *vmdev = device_data; >>> + struct mdev_device *mdev = vmdev->mdev; >>> + struct parent_device *parent = mdev->parent; >>> + unsigned int done = 0; >>> + int ret; >>> + >>> + if (!parent->ops->read) >>> + return -EINVAL; >>> + >>> + while (count) { >> Here, I have to say sorry to you guys for that I didn't notice the >> bad impact of this change to my patches during the v6 discussion. >> >> For vfio-ccw, I introduced an I/O region to input/output I/O >> instruction parameters and results for Qemu. The @count of these data >> currently is 140. So supporting arbitrary lengths in one shot here, and >> also in vfio_mdev_write, seems the better option for this case. >> >> I believe that if the pci drivers want to iterate in a 4 bytes step, you >> can do that in the parent read/write callbacks instead. >> >> What do you think? >> > > I would like to know Alex's thought on this. He raised concern with this > approach in v6 reviews: > "But I think this is exploitable, it lets the user make the kernel > allocate an arbitrarily sized buffer." It is impossible to check count here, because one simply doesn't have the knowledge of this region. VFIO_DEVICE_GET_REGION_INFO was implemented in vfio-mdev.ko, while decoding the vfio_mdev_read to a particular MMIO region was expected to be implemented in vendor driver, that results in unbalanced interfaces. To have balanced interfaces, you either: - call ioctl instead of GET_REGION_INFO - call read instead of decoding REGION or: - call GET_REGION_INFO instead of ioctl - decode REGION in read, and check its validity, call region-specific read function V6 was the latter, v7 is kind of a mixture of these two, while I believe the former will completely address such problem :) -- Thanks, Jike >>> + size_t filled; >>> + >>> + if (count >= 4 && !(*ppos % 4)) { >>> + u32 val; >>> + >>> + ret = parent->ops->read(mdev, (char *)&val, sizeof(val), >>> + *ppos); >>> + if (ret <= 0) >>> + goto read_err; >>> + >>> + if (copy_to_user(buf, &val, sizeof(val))) >>> + goto read_err; >>> + >>> + filled = 4; >>> + } else if (count >= 2 && !(*ppos % 2)) { >>> + u16 val; >>> + >>> + ret = parent->ops->read(mdev, (char *)&val, sizeof(val), >>> + *ppos); >>> + if (ret <= 0) >>> + goto read_err; >>> + >>> + if (copy_to_user(buf, &val, sizeof(val))) >>> + goto read_err; >>> + >>> + filled = 2; >>> + } else { >>> + u8 val; >>> + >>> + ret = parent->ops->read(mdev, &val, sizeof(val), *ppos); >>> + if (ret <= 0) >>> + goto read_err; >>> + >>> + if (copy_to_user(buf, &val, sizeof(val))) >>> + goto read_err; >>> + >>> + filled = 1; >>> + } >>> + >>> + count -= filled; >>> + done += filled; >>> + *ppos += filled; >>> + buf += filled; >>> + } >>> + >>> + return done; >>> + >>> +read_err: >>> + return -EFAULT; >>> +} >> [...] >> >> -------- >> Dong Jia >>
next prev parent reply other threads:[~2016-09-08 2:39 UTC|newest] Thread overview: 162+ messages / expand[flat|nested] mbox.gz Atom feed top 2016-08-25 3:53 [PATCH v7 0/4] Add Mediated device support Kirti Wankhede 2016-08-25 3:53 ` [Qemu-devel] " Kirti Wankhede 2016-08-25 3:53 ` [PATCH v7 1/4] vfio: Mediated device Core driver Kirti Wankhede 2016-08-25 3:53 ` [Qemu-devel] " Kirti Wankhede 2016-09-08 8:09 ` Jike Song 2016-09-08 8:09 ` [Qemu-devel] " Jike Song 2016-09-08 9:38 ` Neo Jia 2016-09-08 9:38 ` [Qemu-devel] " Neo Jia 2016-09-09 6:26 ` Jike Song 2016-09-09 6:26 ` [Qemu-devel] " Jike Song 2016-09-09 17:48 ` Kirti Wankhede 2016-09-09 17:48 ` [Qemu-devel] " Kirti Wankhede 2016-09-09 18:42 ` Alex Williamson 2016-09-09 18:42 ` [Qemu-devel] " Alex Williamson 2016-09-09 19:55 ` Kirti Wankhede 2016-09-09 19:55 ` [Qemu-devel] " Kirti Wankhede 2016-09-12 5:10 ` Jike Song 2016-09-12 5:10 ` [Qemu-devel] " Jike Song 2016-09-12 7:49 ` Kirti Wankhede 2016-09-12 7:49 ` [Qemu-devel] " Kirti Wankhede 2016-09-12 15:53 ` Alex Williamson 2016-09-12 15:53 ` [Qemu-devel] " Alex Williamson 2016-09-19 7:08 ` Jike Song 2016-09-19 7:08 ` [Qemu-devel] " Jike Song 2016-09-19 17:29 ` Kirti Wankhede 2016-09-19 17:29 ` [Qemu-devel] " Kirti Wankhede 2016-09-19 18:11 ` Alex Williamson 2016-09-19 18:11 ` [Qemu-devel] " Alex Williamson 2016-09-19 20:09 ` Kirti Wankhede 2016-09-19 20:09 ` [Qemu-devel] " Kirti Wankhede 2016-09-19 20:59 ` Alex Williamson 2016-09-20 12:48 ` Jike Song 2016-09-20 12:48 ` [Qemu-devel] " Jike Song 2016-08-25 3:53 ` [PATCH v7 2/4] vfio: VFIO driver for mediated devices Kirti Wankhede 2016-08-25 3:53 ` [Qemu-devel] " Kirti Wankhede 2016-08-25 9:22 ` Dong Jia 2016-08-25 9:22 ` [Qemu-devel] " Dong Jia 2016-08-26 14:13 ` Kirti Wankhede 2016-08-26 14:13 ` [Qemu-devel] " Kirti Wankhede 2016-09-08 2:38 ` Jike Song [this message] 2016-09-08 2:38 ` Jike Song 2016-09-19 18:22 ` Kirti Wankhede 2016-09-19 18:22 ` Kirti Wankhede 2016-09-19 18:36 ` Alex Williamson 2016-09-19 18:36 ` Alex Williamson 2016-09-19 19:13 ` Kirti Wankhede 2016-09-19 19:13 ` Kirti Wankhede 2016-09-19 20:03 ` Alex Williamson 2016-09-19 20:03 ` Alex Williamson 2016-09-20 2:50 ` Jike Song 2016-09-20 16:24 ` Alex Williamson 2016-09-21 3:19 ` Jike Song 2016-09-21 4:51 ` Alex Williamson 2016-09-21 5:02 ` Jike Song 2016-09-08 2:45 ` Jike Song 2016-09-08 2:45 ` [Qemu-devel] " Jike Song 2016-09-13 2:35 ` Jike Song 2016-09-13 2:35 ` [Qemu-devel] " Jike Song 2016-09-20 5:48 ` Dong Jia Shi 2016-09-20 5:48 ` [Qemu-devel] " Dong Jia Shi 2016-09-20 6:37 ` Jike Song 2016-09-20 6:37 ` [Qemu-devel] " Jike Song 2016-09-20 12:53 ` Jike Song 2016-09-20 12:53 ` [Qemu-devel] " Jike Song 2016-08-25 3:53 ` [PATCH v7 3/4] vfio iommu: Add support " Kirti Wankhede 2016-08-25 3:53 ` [Qemu-devel] " Kirti Wankhede 2016-08-25 7:29 ` Dong Jia 2016-08-25 7:29 ` [Qemu-devel] " Dong Jia 2016-08-26 13:50 ` Kirti Wankhede 2016-08-26 13:50 ` [Qemu-devel] " Kirti Wankhede 2016-09-29 2:17 ` Jike Song 2016-09-29 2:17 ` [Qemu-devel] " Jike Song 2016-09-29 15:06 ` Kirti Wankhede 2016-09-29 15:06 ` [Qemu-devel] " Kirti Wankhede 2016-09-30 2:58 ` Jike Song 2016-09-30 2:58 ` [Qemu-devel] " Jike Song 2016-09-30 3:10 ` Jike Song 2016-09-30 3:10 ` [Qemu-devel] " Jike Song 2016-09-30 11:44 ` Kirti Wankhede 2016-09-30 11:44 ` [Qemu-devel] " Kirti Wankhede 2016-10-08 7:09 ` Jike Song 2016-10-08 7:09 ` [Qemu-devel] " Jike Song 2016-08-25 3:53 ` [PATCH v7 4/4] docs: Add Documentation for Mediated devices Kirti Wankhede 2016-08-25 3:53 ` [Qemu-devel] " Kirti Wankhede 2016-09-03 16:40 ` Kirti Wankhede 2016-09-03 16:40 ` [Qemu-devel] " Kirti Wankhede 2016-08-30 16:16 ` [PATCH v7 0/4] Add Mediated device support Alex Williamson 2016-08-30 16:16 ` [Qemu-devel] " Alex Williamson 2016-08-31 6:12 ` Tian, Kevin 2016-08-31 6:12 ` [Qemu-devel] " Tian, Kevin 2016-08-31 7:04 ` Jike Song 2016-08-31 7:04 ` [Qemu-devel] " Jike Song 2016-08-31 15:48 ` Alex Williamson 2016-08-31 15:48 ` [Qemu-devel] " Alex Williamson 2016-09-01 4:09 ` Tian, Kevin 2016-09-01 4:09 ` [Qemu-devel] " Tian, Kevin 2016-09-01 4:10 ` Tian, Kevin 2016-09-01 4:10 ` [Qemu-devel] " Tian, Kevin 2016-09-01 18:22 ` Kirti Wankhede 2016-09-01 18:22 ` [Qemu-devel] " Kirti Wankhede 2016-09-01 20:01 ` Alex Williamson 2016-09-01 20:01 ` [Qemu-devel] " Alex Williamson 2016-09-02 6:17 ` Kirti Wankhede 2016-09-02 6:17 ` [Qemu-devel] " Kirti Wankhede 2016-09-01 16:47 ` Michal Privoznik 2016-09-01 16:59 ` Alex Williamson 2016-09-01 16:59 ` [Qemu-devel] " Alex Williamson 2016-09-02 4:48 ` Michal Privoznik 2016-09-02 5:21 ` Kirti Wankhede 2016-09-02 10:05 ` Paolo Bonzini 2016-09-02 17:15 ` Kirti Wankhede 2016-09-02 17:25 ` Paolo Bonzini 2016-09-02 18:33 ` Kirti Wankhede 2016-09-02 20:29 ` [libvirt] " John Ferlan 2016-09-02 20:29 ` [Qemu-devel] [libvirt] " John Ferlan 2016-09-03 16:31 ` Kirti Wankhede 2016-09-03 16:31 ` [Qemu-devel] " Kirti Wankhede 2016-09-06 17:54 ` [libvirt] [Qemu-devel] " Alex Williamson 2016-09-06 17:54 ` [Qemu-devel] [libvirt] " Alex Williamson 2016-09-02 21:48 ` [Qemu-devel] " Paolo Bonzini 2016-09-03 11:56 ` [libvirt] " John Ferlan 2016-09-03 11:56 ` [Qemu-devel] [libvirt] " John Ferlan 2016-09-03 13:07 ` [libvirt] [Qemu-devel] " Paolo Bonzini 2016-09-03 13:07 ` [Qemu-devel] [libvirt] " Paolo Bonzini 2016-09-03 17:47 ` Kirti Wankhede 2016-09-03 17:47 ` [Qemu-devel] " Kirti Wankhede 2016-09-03 16:34 ` [Qemu-devel] " Kirti Wankhede 2016-09-06 17:40 ` Alex Williamson 2016-09-06 19:35 ` Kirti Wankhede 2016-09-06 21:28 ` Alex Williamson 2016-09-07 8:22 ` Tian, Kevin 2016-09-07 8:22 ` Tian, Kevin 2016-09-07 16:00 ` Alex Williamson 2016-09-07 16:15 ` Kirti Wankhede 2016-09-07 16:44 ` Alex Williamson 2016-09-07 18:06 ` Kirti Wankhede 2016-09-07 22:13 ` Alex Williamson 2016-09-08 18:48 ` Kirti Wankhede 2016-09-08 20:51 ` Alex Williamson 2016-09-07 18:17 ` Neo Jia 2016-09-07 18:27 ` Daniel P. Berrange 2016-09-07 18:32 ` Neo Jia 2016-09-07 6:48 ` Tian, Kevin 2016-09-07 6:48 ` Tian, Kevin 2016-09-02 20:19 ` [libvirt] " John Ferlan 2016-09-02 20:19 ` [Qemu-devel] [libvirt] " John Ferlan 2016-09-02 21:44 ` [libvirt] [Qemu-devel] " Paolo Bonzini 2016-09-02 21:44 ` [Qemu-devel] [libvirt] " Paolo Bonzini 2016-09-02 23:57 ` [libvirt] [Qemu-devel] " Laine Stump 2016-09-02 23:57 ` [Qemu-devel] [libvirt] " Laine Stump 2016-09-03 16:49 ` [libvirt] [Qemu-devel] " Kirti Wankhede 2016-09-03 16:49 ` [Qemu-devel] [libvirt] " Kirti Wankhede 2016-09-05 7:52 ` [libvirt] [Qemu-devel] " Paolo Bonzini 2016-09-05 7:52 ` [Qemu-devel] [libvirt] " Paolo Bonzini 2016-09-03 11:57 ` [libvirt] [Qemu-devel] " John Ferlan 2016-09-03 11:57 ` [Qemu-devel] [libvirt] " John Ferlan 2016-09-05 7:54 ` [libvirt] [Qemu-devel] " Paolo Bonzini 2016-09-05 7:54 ` [Qemu-devel] [libvirt] " Paolo Bonzini 2016-09-02 17:55 ` [libvirt] [Qemu-devel] " Laine Stump 2016-09-02 17:55 ` [Qemu-devel] [libvirt] " Laine Stump 2016-09-02 19:15 ` Alex Williamson 2016-09-02 19:15 ` [Qemu-devel] " Alex Williamson
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=57D0CF08.6020106@intel.com \ --to=jike.song@intel.com \ --cc=alex.williamson@redhat.com \ --cc=bjsdjshi@linux.vnet.ibm.com \ --cc=cjia@nvidia.com \ --cc=kevin.tian@intel.com \ --cc=kraxel@redhat.com \ --cc=kvm@vger.kernel.org \ --cc=kwankhede@nvidia.com \ --cc=pbonzini@redhat.com \ --cc=qemu-devel@nongnu.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.