From: Jason Gunthorpe <jgg@nvidia.com>
To: Alex Williamson <alex.williamson@redhat.com>
Cc: Ankit Agrawal <ankita@nvidia.com>,
Brett Creeley <brett.creeley@amd.com>,
Giovanni Cabiddu <giovanni.cabiddu@intel.com>,
Kevin Tian <kevin.tian@intel.com>,
kvm@vger.kernel.org, Longfang Liu <liulongfang@huawei.com>,
qat-linux@intel.com, virtualization@lists.linux.dev,
Xin Zeng <xin.zeng@intel.com>, Yishai Hadas <yishaih@nvidia.com>,
Matthew Rosato <mjrosato@linux.ibm.com>,
Nicolin Chen <nicolinc@nvidia.com>,
patches@lists.linux.dev,
Shameer Kolothum <shameerali.kolothum.thodi@huawei.com>,
Terrence Xu <terrence.xu@intel.com>,
Yanting Jiang <yanting.jiang@intel.com>,
Yi Liu <yi.l.liu@intel.com>,
Zhenzhong Duan <zhenzhong.duan@intel.com>
Subject: Re: [PATCH] vfio/pci: Do vf_token checks for VFIO_DEVICE_BIND_IOMMUFD
Date: Wed, 2 Jul 2025 11:56:30 -0300 [thread overview]
Message-ID: <20250702145630.GA1139770@nvidia.com> (raw)
In-Reply-To: <20250624140604.6330c656.alex.williamson@redhat.com>
On Tue, Jun 24, 2025 at 02:06:04PM -0600, Alex Williamson wrote:
> > This is used to control access to a VF unless there is co-ordination with
> > the owner of the PF.
> >
> > Since we no longer have a device name pass the token directly though
>
> s/name pass/name, pass/ s/though/through/
Got it
> > @@ -132,6 +132,7 @@ struct vfio_device_ops {
> > int (*mmap)(struct vfio_device *vdev, struct vm_area_struct *vma);
> > void (*request)(struct vfio_device *vdev, unsigned int count);
> > int (*match)(struct vfio_device *vdev, char *buf);
> > + int (*match_token_uuid)(struct vfio_device *vdev, const uuid_t *uuid);
> > void (*dma_unmap)(struct vfio_device *vdev, u64 iova, u64 length);
> > int (*device_feature)(struct vfio_device *device, u32 flags,
> > void __user *arg, size_t argsz);
>
> Update the structure comments.
* @match_token_uuid: Optional device token match/validation. Return 0
* if the uuid is valid for the device, -errno otherwise. uuid is NULL
* if none was provided.
> > diff --git a/include/linux/vfio_pci_core.h b/include/linux/vfio_pci_core.h
> > index fbb472dd99b361..f541044e42a2ad 100644
> > --- a/include/linux/vfio_pci_core.h
> > +++ b/include/linux/vfio_pci_core.h
> > @@ -122,6 +122,8 @@ ssize_t vfio_pci_core_write(struct vfio_device *core_vdev, const char __user *bu
> > int vfio_pci_core_mmap(struct vfio_device *core_vdev, struct vm_area_struct *vma);
> > void vfio_pci_core_request(struct vfio_device *core_vdev, unsigned int count);
> > int vfio_pci_core_match(struct vfio_device *core_vdev, char *buf);
> > +int vfio_pci_core_match_token_uuid(struct vfio_device *core_vdev,
> > + const uuid_t *uuid);
> > int vfio_pci_core_enable(struct vfio_pci_core_device *vdev);
> > void vfio_pci_core_disable(struct vfio_pci_core_device *vdev);
> > void vfio_pci_core_finish_enable(struct vfio_pci_core_device *vdev);
> > diff --git a/include/uapi/linux/vfio.h b/include/uapi/linux/vfio.h
> > index 5764f315137f99..48233ec4daf7b4 100644
> > --- a/include/uapi/linux/vfio.h
> > +++ b/include/uapi/linux/vfio.h
> > @@ -901,14 +901,18 @@ struct vfio_device_feature {
> >
> > #define VFIO_DEVICE_FEATURE _IO(VFIO_TYPE, VFIO_BASE + 17)
> >
> > +#define VFIO_DEVICE_BIND_TOKEN (1 << 0)
>
> We tend to define ioctl flags within the ioctl data structure and
> include "_FLAG_" in the name.
*/
struct vfio_device_bind_iommufd {
__u32 argsz;
__u32 flags;
#define VFIO_DEVICE_BIND_FLAG_TOKEN (1 << 0)
__s32 iommufd;
> > @@ -924,6 +934,7 @@ struct vfio_device_bind_iommufd {
> > __u32 flags;
> > __s32 iommufd;
> > __u32 out_devid;
> > + __aligned_u64 token_uuid_ptr;
> > };
>
> So we're expecting in the general case, old code doesn't set the flag,
> doesn't need a token, continues to work.
Yes
> There's potentially a narrow case of old code that should have
> required a token, which now intentionally breaks.
Yes
> We're not offering an introspection mechanism
> here, but doing so also doesn't add a lot of value.
Right.
> Userspace needs to know the token to pass anyway. Is that how you
> see it?
Yes, we are fixing a security bug here.
> Do note that QEMU already has support for this in the legacy interface
> and should just need to reparse the token from the name provided
> through the attach_device callback and pass it through to the
> iommufd_cdev_connect_and_bind() function.
Yes, that sounds right.
I will repost it and hopefully someone has an easy test environment
Jason
next prev parent reply other threads:[~2025-07-02 14:56 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-06-24 18:34 [PATCH] vfio/pci: Do vf_token checks for VFIO_DEVICE_BIND_IOMMUFD Jason Gunthorpe
2025-06-24 20:06 ` Alex Williamson
2025-07-02 14:56 ` Jason Gunthorpe [this message]
2025-07-03 6:40 ` Tian, Kevin
2025-07-03 13:41 ` Jason Gunthorpe
2025-07-10 8:29 ` Tian, Kevin
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=20250702145630.GA1139770@nvidia.com \
--to=jgg@nvidia.com \
--cc=alex.williamson@redhat.com \
--cc=ankita@nvidia.com \
--cc=brett.creeley@amd.com \
--cc=giovanni.cabiddu@intel.com \
--cc=kevin.tian@intel.com \
--cc=kvm@vger.kernel.org \
--cc=liulongfang@huawei.com \
--cc=mjrosato@linux.ibm.com \
--cc=nicolinc@nvidia.com \
--cc=patches@lists.linux.dev \
--cc=qat-linux@intel.com \
--cc=shameerali.kolothum.thodi@huawei.com \
--cc=terrence.xu@intel.com \
--cc=virtualization@lists.linux.dev \
--cc=xin.zeng@intel.com \
--cc=yanting.jiang@intel.com \
--cc=yi.l.liu@intel.com \
--cc=yishaih@nvidia.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 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.