From: Yi Liu <yi.l.liu@intel.com>
To: Alex Williamson <alex.williamson@redhat.com>
Cc: Jason Gunthorpe <jgg@nvidia.com>,
"Tian, Kevin" <kevin.tian@intel.com>,
"joro@8bytes.org" <joro@8bytes.org>,
"baolu.lu@linux.intel.com" <baolu.lu@linux.intel.com>,
"eric.auger@redhat.com" <eric.auger@redhat.com>,
"nicolinc@nvidia.com" <nicolinc@nvidia.com>,
"kvm@vger.kernel.org" <kvm@vger.kernel.org>,
"chao.p.peng@linux.intel.com" <chao.p.peng@linux.intel.com>,
"iommu@lists.linux.dev" <iommu@lists.linux.dev>,
"Duan, Zhenzhong" <zhenzhong.duan@intel.com>,
"linux-kselftest@vger.kernel.org"
<linux-kselftest@vger.kernel.org>,
"vasant.hegde@amd.com" <vasant.hegde@amd.com>
Subject: Re: [PATCH v3 3/4] vfio: Add VFIO_DEVICE_PASID_[AT|DE]TACH_IOMMUFD_PT
Date: Thu, 31 Oct 2024 15:23:12 +0800 [thread overview]
Message-ID: <2e04d06c-24b5-4162-8b94-740b9544f951@intel.com> (raw)
In-Reply-To: <20241030115142.47272017.alex.williamson@redhat.com>
On 2024/10/31 01:51, Alex Williamson wrote:
> On Wed, 30 Oct 2024 20:54:09 +0800
> Yi Liu <yi.l.liu@intel.com> wrote:
>
>> Hi Alex,
>>
>> On 2024/10/18 13:40, Yi Liu wrote:
>>>>>> I think we need to monotonically increase the structure size,
>>>>>> but maybe something more like below, using flags. The expectation
>>>>>> would be that if we add another flag that extends the structure, we'd
>>>>>> test that flag after PASID and clobber xend to a new value further into
>>>>>> the new structure. We'd also add that flag to the flags mask, but we'd
>>>>>> share the copy code.
>>>>>
>>>>> agree, this share code might be needed for other path as well. Some macros
>>>>> I guess.
>>>>>
>>>>>>
>>>>>> if (attach.argsz < minsz)
>>>>>> return -EINVAL;
>>>>>>
>>>>>> if (attach.flags & (~VFIO_DEVICE_ATTACH_PASID))
>>>>>> return -EINVAL;
>>>>>>
>>>>>> if (attach.flags & VFIO_DEVICE_ATTACH_PASID)
>>>>>> xend = offsetofend(struct vfio_device_attach_iommufd_pt, pasid);
>>>>>>
>>>>>> if (xend) {
>>>>>> if (attach.argsz < xend)
>>>>>> return -EINVAL;
>>
>> Need to check the future usage of 'xend'. In understanding, 'xend' should
>> always be offsetofend(struct, the_last_field). A userspace that uses @pasid
>> field would set argsz >= offsetofend(struct, pasid), most likely it would
>> just set argsz==offsetofend(struct, pasid). If so, such userspace would be
>> failed when running on a kernel that has added new fields behind @pasid.
>
> No, xend denotes the end of the structure we need to satisfy the flags
> that are requested by the user.
>
>> Say two decades later, we add a new field (say @xyz) to this user struct,
>> the 'xend' would be updated to be offsetofend(struct, xyz). This 'xend'
>> would be larger than the argsz provided by the aforementioned userspace.
>> Hence it would be failed in the above check.
>
> New field xyz would require a new flag, VFIO_DEVICE_XYZ and we'd extend
> the above code as:
>
> if (attach.argsz < minsz)
> return -EINVAL;
>
> if (attach.flags & (~(VFIO_DEVICE_ATTACH_PASID |
> VFIO_DEVICE_XYZ)))
> return -EINVAL;
>
> if (attach.flags & VFIO_DEVICE_ATTACH_PASID)
> xend = offsetofend(struct vfio_device_attach_iommufd_pt, pasid);
>
> if (attach.flags & VFIO_DEVICE_XYZ)
> xend = offsetofend(struct vfio_device_attach_iommufd_pt, xyz);
>
> if (xend) {
> if (attach.argsz < xend)
> return -EINVAL;
>
> New userspace can provide argsz = offsetofend(, xyz), just as it could
> provide argsz = PAGE_SIZE now if it really wanted, but argsz > minsz is
> only required if the user sets any of these new flags. Therefore old
> userspace on new kernel continues to work.
got it. This should work. thanks.:)
>> To make it work, I'm
>> considering to make some changes to the code. When argsz < xend, we only
>> copy extra data with size==argsz-minsz. Just as the below.
>>
>> if (xend) {
>> unsigned long size;
>>
>> if (attach.argsz < xend)
>
> This is an -EINVAL condition, xend tracks the flags the user has set.
> The user must provide a sufficient buffer for the flags they've set.
>
>> size = attach.argsz - minsz;
>> else
>> size = xend - minsz;
>
> This is the only correct copy size.
>
>>
>> if (copy_from_user((void *)&attach + minsz,
>> (void __user *)arg + minsz, size))
>> return -EFAULT;
>> }
>>
>> However, it seems to have another problem. If the userspace that uses
>> @pasid set the argsz==offsetofend(struct, pasid) - 1, such userspace is
>> not supposed to work and should be failed by kernel. is it? However, my
>> above code cannot fail it. :(
>>
>> Any suggestion about it?
>
> If a user sets the ATTACH_PASID flag and argsz is less than
> offsetofend(struct, pasid), we need to return -EINVAL as indicated
> above. Thanks,
yep.
>
>>
>>>>>>
>>>>>> if (copy_from_user((void *)&attach + minsz,
>>>>>> (void __user *)arg + minsz, xend - minsz))
>>>>>> return -EFAULT;
>>>>>> }
>>>>>
>>
>
>
--
Regards,
Yi Liu
next prev parent reply other threads:[~2024-10-31 7:18 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-09-12 13:17 [PATCH v3 0/4] vfio-pci support pasid attach/detach Yi Liu
2024-09-12 13:17 ` [PATCH v3 1/4] ida: Add ida_find_first_range() Yi Liu
2024-09-12 15:11 ` Matthew Wilcox
2024-09-13 11:45 ` Yi Liu
2024-09-13 15:09 ` Matthew Wilcox
2024-09-14 4:16 ` Yi Liu
2024-09-26 19:11 ` Jason Gunthorpe
2024-09-30 7:49 ` Tian, Kevin
2024-09-12 13:17 ` [PATCH v3 2/4] vfio-iommufd: Support pasid [at|de]tach for physical VFIO devices Yi Liu
2024-09-26 19:13 ` Jason Gunthorpe
2024-09-12 13:17 ` [PATCH v3 3/4] vfio: Add VFIO_DEVICE_PASID_[AT|DE]TACH_IOMMUFD_PT Yi Liu
2024-09-26 19:16 ` Jason Gunthorpe
2024-09-30 7:55 ` Tian, Kevin
2024-10-01 12:11 ` Jason Gunthorpe
2024-10-12 13:49 ` Yi Liu
2024-10-14 15:49 ` Alex Williamson
2024-10-15 11:07 ` Yi Liu
2024-10-15 16:22 ` Alex Williamson
2024-10-16 3:35 ` Yi Liu
2024-10-16 16:11 ` Alex Williamson
2024-10-18 5:40 ` Yi Liu
2024-10-30 12:54 ` Yi Liu
2024-10-30 17:51 ` Alex Williamson
2024-10-31 7:23 ` Yi Liu [this message]
2024-09-12 13:17 ` [PATCH v3 4/4] iommufd: Extend IOMMU_GET_HW_INFO to report PASID capability Yi Liu
2024-09-26 19:35 ` Jason Gunthorpe
2024-09-27 3:08 ` Yi Liu
2024-09-30 8:03 ` Tian, Kevin
2024-10-22 10:08 ` Vasant Hegde
2024-10-28 6:41 ` Zhangfei Gao
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=2e04d06c-24b5-4162-8b94-740b9544f951@intel.com \
--to=yi.l.liu@intel.com \
--cc=alex.williamson@redhat.com \
--cc=baolu.lu@linux.intel.com \
--cc=chao.p.peng@linux.intel.com \
--cc=eric.auger@redhat.com \
--cc=iommu@lists.linux.dev \
--cc=jgg@nvidia.com \
--cc=joro@8bytes.org \
--cc=kevin.tian@intel.com \
--cc=kvm@vger.kernel.org \
--cc=linux-kselftest@vger.kernel.org \
--cc=nicolinc@nvidia.com \
--cc=vasant.hegde@amd.com \
--cc=zhenzhong.duan@intel.com \
/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: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).