Intel-GFX Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: Yi Liu <yi.l.liu@intel.com>
To: joro@8bytes.org, alex.williamson@redhat.com, jgg@nvidia.com,
	kevin.tian@intel.com, robin.murphy@arm.com
Cc: linux-s390@vger.kernel.org, yi.l.liu@intel.com,
	yi.y.sun@linux.intel.com, kvm@vger.kernel.org,
	mjrosato@linux.ibm.com, jasowang@redhat.com, cohuck@redhat.com,
	peterx@redhat.com, eric.auger@redhat.com, nicolinc@nvidia.com,
	shameerali.kolothum.thodi@huawei.com,
	suravee.suthikulpanit@amd.com, chao.p.peng@linux.intel.com,
	lulu@redhat.com, intel-gvt-dev@lists.freedesktop.org,
	intel-gfx@lists.freedesktop.org
Subject: [Intel-gfx] [PATCH v3 12/15] vfio: Make vfio_device_open() single open for device cdev path
Date: Mon, 13 Feb 2023 07:13:45 -0800	[thread overview]
Message-ID: <20230213151348.56451-13-yi.l.liu@intel.com> (raw)
In-Reply-To: <20230213151348.56451-1-yi.l.liu@intel.com>

With the introduction of vfio device cdev, userspace can get device
access by either the legacy group path or the cdev path. For VFIO devices,
it can only be opened by one of the group path and the cdev path at one
time. e.g. when the device is opened via cdev path, the group path should
be failed. Both paths will call into vfio_device_open(), so the exclusion
is done in it.

VFIO group has historically allowed multi-open of the device FD. This
was made secure because the "open" was executed via an ioctl to the
group FD which is itself only single open.

However, no known use of multiple device FDs today. It is kind of a
strange thing to do because new device FDs can naturally be created
via dup().

When we implement the new device uAPI (only used in cdev path) there is
no natural way to allow the device itself from being multi-opened in a
secure manner. Without the group FD we cannot prove the security context
of the opener.

Thus, when moving to the new uAPI we block the ability to multi-open
the device. Old group path still allows it.

vfio_device_open() needs to sustain both the legacy behavior i.e. multi-open
in the group path and the new behavior i.e. single-open in the cdev path.
This mixture leads to the introduction of a new is_cdev_device flag in struct
vfio_device_file.

Signed-off-by: Yi Liu <yi.l.liu@intel.com>
---
 drivers/vfio/vfio.h      |  2 ++
 drivers/vfio/vfio_main.c | 16 +++++++++++++++-
 2 files changed, 17 insertions(+), 1 deletion(-)

diff --git a/drivers/vfio/vfio.h b/drivers/vfio/vfio.h
index 7a77fb12bd2c..620ebcf966fc 100644
--- a/drivers/vfio/vfio.h
+++ b/drivers/vfio/vfio.h
@@ -18,6 +18,8 @@ struct vfio_container;
 
 struct vfio_device_file {
 	struct vfio_device *device;
+	bool is_cdev_device;
+
 	bool access_granted;
 	spinlock_t kvm_ref_lock; /* protect kvm field */
 	struct kvm *kvm;
diff --git a/drivers/vfio/vfio_main.c b/drivers/vfio/vfio_main.c
index 05dd4b89e9d1..c0be4b27f96c 100644
--- a/drivers/vfio/vfio_main.c
+++ b/drivers/vfio/vfio_main.c
@@ -472,6 +472,15 @@ int vfio_device_open(struct vfio_device_file *df,
 
 	lockdep_assert_held(&device->dev_set->lock);
 
+	/*
+	 * Device cdev path cannot support multiple device open since
+	 * it doesn't have a secure way for it. So a second device
+	 * open attempt should be failed if the caller is from a cdev
+	 * path.
+	 */
+	if (device->open_count != 0 && df->is_cdev_device)
+		return -EINVAL;
+
 	device->open_count++;
 	if (device->open_count == 1) {
 		ret = vfio_device_first_open(df, dev_id, pt_id);
@@ -543,7 +552,12 @@ static int vfio_device_fops_release(struct inode *inode, struct file *filep)
 	struct vfio_device_file *df = filep->private_data;
 	struct vfio_device *device = df->device;
 
-	vfio_device_group_close(df);
+	/*
+	 * group path supports multiple device open, while cdev doesn't.
+	 * So use vfio_device_group_close() for !is_cdev_device case.
+	 */
+	if (!df->is_cdev_device)
+		vfio_device_group_close(df);
 
 	vfio_device_put_registration(device);
 
-- 
2.34.1


  parent reply	other threads:[~2023-02-13 15:14 UTC|newest]

Thread overview: 68+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-02-13 15:13 [Intel-gfx] [PATCH v3 00/15] Add vfio_device cdev for iommufd support Yi Liu
2023-02-13 15:13 ` [Intel-gfx] [PATCH v3 01/15] vfio: Allocate per device file structure Yi Liu
2023-02-13 15:13 ` [Intel-gfx] [PATCH v3 02/15] vfio: Refine vfio file kAPIs Yi Liu
2023-02-13 15:13 ` [Intel-gfx] [PATCH v3 03/15] vfio: Accept vfio device file in the driver facing kAPI Yi Liu
2023-02-13 23:21   ` Alex Williamson
2023-02-14  2:19     ` Liu, Yi L
2023-02-13 23:43   ` Jason Gunthorpe
2023-02-14  2:02     ` Liu, Yi L
2023-02-14  7:19       ` Liu, Yi L
2023-02-17 10:55         ` Liu, Yi L
2023-02-17 15:59           ` Jason Gunthorpe
2023-02-18  2:54             ` Liu, Yi L
2023-02-15 12:38       ` Jason Gunthorpe
2023-02-15 14:43         ` Liu, Yi L
2023-02-15 14:46           ` Jason Gunthorpe
2023-02-15 15:32             ` Alex Williamson
2023-02-15 17:04               ` Jason Gunthorpe
2023-02-15 17:19                 ` Alex Williamson
2023-02-15 17:33                   ` Jason Gunthorpe
2023-02-13 15:13 ` [Intel-gfx] [PATCH v3 04/15] kvm/vfio: Rename kvm_vfio_group to prepare for accepting vfio device fd Yi Liu
2023-02-13 15:13 ` [Intel-gfx] [PATCH v3 05/15] kvm/vfio: Accept vfio device file from userspace Yi Liu
2023-02-14 22:26   ` Alex Williamson
2023-02-14 23:25     ` Jason Gunthorpe
2023-02-14 23:42       ` Alex Williamson
2023-02-15  0:17         ` Jason Gunthorpe
2023-02-15  0:27           ` Timothy Pearson
2023-02-17  5:34           ` Liu, Yi L
2023-02-17  5:48             ` Liu, Yi L
2023-02-17 16:00               ` Jason Gunthorpe
2023-02-15  7:37       ` Liu, Yi L
2023-02-13 15:13 ` [Intel-gfx] [PATCH v3 06/15] vfio: Pass struct vfio_device_file * to vfio_device_open/close() Yi Liu
2023-02-13 15:13 ` [Intel-gfx] [PATCH v3 07/15] vfio: Block device access via device fd until device is opened Yi Liu
2023-02-14 22:46   ` Alex Williamson
2023-02-15  6:12     ` Liu, Yi L
2023-02-13 15:13 ` [Intel-gfx] [PATCH v3 08/15] vfio: Add infrastructure for bind_iommufd from userspace Yi Liu
2023-02-13 15:13 ` [Intel-gfx] [PATCH v3 09/15] vfio-iommufd: Add detach_ioas support for physical VFIO devices Yi Liu
2023-02-14  8:05   ` Tian, Kevin
2023-02-13 15:13 ` [Intel-gfx] [PATCH v3 10/15] vfio-iommufd: Add detach_ioas for emulated " Yi Liu
2023-02-14  8:06   ` Tian, Kevin
2023-02-13 15:13 ` [Intel-gfx] [PATCH v3 11/15] vfio: Add cdev_device_open_cnt to vfio_group Yi Liu
2023-02-14  8:18   ` Tian, Kevin
2023-02-13 15:13 ` Yi Liu [this message]
2023-02-14  8:25   ` [Intel-gfx] [PATCH v3 12/15] vfio: Make vfio_device_open() single open for device cdev path Tian, Kevin
2023-02-13 15:13 ` [Intel-gfx] [PATCH v3 13/15] vfio: Add cdev for vfio_device Yi Liu
2023-02-14  8:32   ` Tian, Kevin
2023-02-14  8:35     ` Liu, Yi L
2023-02-13 15:13 ` [Intel-gfx] [PATCH v3 14/15] vfio: Add ioctls for device cdev using iommufd Yi Liu
2023-02-14  8:53   ` Tian, Kevin
2023-02-14 23:39   ` Yan Zhao
2023-02-15  2:04     ` Tian, Kevin
2023-02-15  7:37       ` Liu, Yi L
2023-02-16  8:24   ` Yan Zhao
2023-02-16  9:10     ` Liu, Yi L
2023-02-16  9:23       ` Yan Zhao
2023-02-16 10:28         ` Liu, Yi L
2023-02-16 14:24           ` Jason Gunthorpe
2023-02-13 15:13 ` [Intel-gfx] [PATCH v3 15/15] vfio: Compile group optionally Yi Liu
2023-02-13 15:30 ` [Intel-gfx] ✗ Fi.CI.BUILD: failure for Add vfio_device cdev for iommufd support (rev2) Patchwork
2023-02-13 19:47 ` [Intel-gfx] [PATCH v3 00/15] Add vfio_device cdev for iommufd support Alex Williamson
2023-02-13 23:21   ` Jason Gunthorpe
2023-02-14 15:15     ` Liu, Yi L
2023-02-14 15:54       ` Alex Williamson
2023-02-14 16:48         ` Jason Gunthorpe
2023-02-14  1:55   ` Liu, Yi L
2023-02-14 15:47     ` Alex Williamson
2023-02-15  7:54       ` Liu, Yi L
2023-02-15 20:09         ` Alex Williamson
2023-02-16  2:53           ` Liu, Yi L

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=20230213151348.56451-13-yi.l.liu@intel.com \
    --to=yi.l.liu@intel.com \
    --cc=alex.williamson@redhat.com \
    --cc=chao.p.peng@linux.intel.com \
    --cc=cohuck@redhat.com \
    --cc=eric.auger@redhat.com \
    --cc=intel-gfx@lists.freedesktop.org \
    --cc=intel-gvt-dev@lists.freedesktop.org \
    --cc=jasowang@redhat.com \
    --cc=jgg@nvidia.com \
    --cc=joro@8bytes.org \
    --cc=kevin.tian@intel.com \
    --cc=kvm@vger.kernel.org \
    --cc=linux-s390@vger.kernel.org \
    --cc=lulu@redhat.com \
    --cc=mjrosato@linux.ibm.com \
    --cc=nicolinc@nvidia.com \
    --cc=peterx@redhat.com \
    --cc=robin.murphy@arm.com \
    --cc=shameerali.kolothum.thodi@huawei.com \
    --cc=suravee.suthikulpanit@amd.com \
    --cc=yi.y.sun@linux.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