From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 3FB92C74A44 for ; Wed, 8 Mar 2023 13:32:58 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230484AbjCHNc4 (ORCPT ); Wed, 8 Mar 2023 08:32:56 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:41430 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230403AbjCHNc1 (ORCPT ); Wed, 8 Mar 2023 08:32:27 -0500 Received: from mga14.intel.com (mga14.intel.com [192.55.52.115]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 83F5D8EA02; Wed, 8 Mar 2023 05:30:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1678282253; x=1709818253; h=from:to:cc:subject:date:message-id:in-reply-to: references:mime-version:content-transfer-encoding; bh=voMqIPw9OlY9tCQvPK26CPNnMsuw9NBE4JXA1W35rMo=; b=Do/X/L6dSb7gVocEYxL+iadnKjlCjd1FVUZPgmksPubicjWV0IqGCusJ 0cUJSgt8gXDQtjLk2wDagz1grORmxTMVqFiHar7f3F+cA2MirsabFIwCx lPjNHOuYjGysP0c1gMfh4EL0T8u/1bopx/EQ+SrXDREjJuLMuX9DX89AP /j/va7/g3QYQopqBAn4/FKWAuvqF3W/vlNepRSbUI1RcxzSjWiWvpcelo 1cV0RGq+noxNqsmmhJPdiI+67LH30iwAh7hGER1mb1UJUHCuiqA57Kw/S /t0S33URAfwEGc2dec6SJm/kQBafVmNpw25VtYv5UlsuThAFR1d046b+g Q==; X-IronPort-AV: E=McAfee;i="6500,9779,10642"; a="336165262" X-IronPort-AV: E=Sophos;i="5.98,244,1673942400"; d="scan'208";a="336165262" Received: from fmsmga006.fm.intel.com ([10.253.24.20]) by fmsmga103.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 08 Mar 2023 05:29:32 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=McAfee;i="6500,9779,10642"; a="922789410" X-IronPort-AV: E=Sophos;i="5.98,244,1673942400"; d="scan'208";a="922789410" Received: from 984fee00a4c6.jf.intel.com ([10.165.58.231]) by fmsmga006.fm.intel.com with ESMTP; 08 Mar 2023 05:29:31 -0800 From: Yi Liu To: alex.williamson@redhat.com, jgg@nvidia.com, kevin.tian@intel.com Cc: joro@8bytes.org, robin.murphy@arm.com, cohuck@redhat.com, eric.auger@redhat.com, nicolinc@nvidia.com, kvm@vger.kernel.org, mjrosato@linux.ibm.com, chao.p.peng@linux.intel.com, yi.l.liu@intel.com, yi.y.sun@linux.intel.com, peterx@redhat.com, jasowang@redhat.com, shameerali.kolothum.thodi@huawei.com, lulu@redhat.com, suravee.suthikulpanit@amd.com, intel-gvt-dev@lists.freedesktop.org, intel-gfx@lists.freedesktop.org, linux-s390@vger.kernel.org, xudong.hao@intel.com, yan.y.zhao@intel.com, terrence.xu@intel.com Subject: [PATCH v6 15/24] vfio: Make vfio_device_open() single open for device cdev path Date: Wed, 8 Mar 2023 05:28:54 -0800 Message-Id: <20230308132903.465159-16-yi.l.liu@intel.com> X-Mailer: git-send-email 2.34.1 In-Reply-To: <20230308132903.465159-1-yi.l.liu@intel.com> References: <20230308132903.465159-1-yi.l.liu@intel.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Precedence: bulk List-ID: X-Mailing-List: linux-s390@vger.kernel.org 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 storing a vfio_group pointer in struct vfio_device_file. Only the group path would set it, cdev path never sets it. Signed-off-by: Yi Liu Reviewed-by: Kevin Tian --- drivers/vfio/group.c | 2 ++ drivers/vfio/vfio.h | 2 ++ drivers/vfio/vfio_main.c | 7 +++++++ 3 files changed, 11 insertions(+) diff --git a/drivers/vfio/group.c b/drivers/vfio/group.c index 63aafd59278d..f067a6a7bbd2 100644 --- a/drivers/vfio/group.c +++ b/drivers/vfio/group.c @@ -254,6 +254,8 @@ static struct file *vfio_device_open_file(struct vfio_device *device) goto err_out; } + df->group = device->group; + ret = vfio_device_group_open(df); if (ret) goto err_free; diff --git a/drivers/vfio/vfio.h b/drivers/vfio/vfio.h index e1b8763e443e..11397cc95e0b 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; + struct vfio_group *group; + 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 cf9994a65df3..aa31aae33407 100644 --- a/drivers/vfio/vfio_main.c +++ b/drivers/vfio/vfio_main.c @@ -477,6 +477,13 @@ int vfio_device_open(struct vfio_device_file *df) lockdep_assert_held(&device->dev_set->lock); + /* + * Only group path supports multiple device open. cdev path + * doesn't have a secure way for it. + */ + if (device->open_count != 0 && !df->group) + return -EINVAL; + device->open_count++; if (device->open_count == 1) { ret = vfio_device_first_open(df); -- 2.34.1