Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
From:   "Tian, Kevin" <kevin.tian@intel.com>
To:     Jason Gunthorpe <jgg@nvidia.com>
CC:     David Gibson <david@gibson.dropbear.id.au>,
        "Liu, Yi L" <yi.l.liu@intel.com>,
        "alex.williamson@redhat.com" <alex.williamson@redhat.com>,
        "hch@lst.de" <hch@lst.de>,
        "jasowang@redhat.com" <jasowang@redhat.com>,
        "joro@8bytes.org" <joro@8bytes.org>,
        "jean-philippe@linaro.org" <jean-philippe@linaro.org>,
        "parav@mellanox.com" <parav@mellanox.com>,
        "lkml@metux.net" <lkml@metux.net>,
        "pbonzini@redhat.com" <pbonzini@redhat.com>,
        "lushenming@huawei.com" <lushenming@huawei.com>,
        "eric.auger@redhat.com" <eric.auger@redhat.com>,
        "corbet@lwn.net" <corbet@lwn.net>,
        "Raj, Ashok" <ashok.raj@intel.com>,
        "yi.l.liu@linux.intel.com" <yi.l.liu@linux.intel.com>,
        "Tian, Jun J" <jun.j.tian@intel.com>, "Wu, Hao" <hao.wu@intel.com>,
        "Jiang, Dave" <dave.jiang@intel.com>,
        "jacob.jun.pan@linux.intel.com" <jacob.jun.pan@linux.intel.com>,
        "kwankhede@nvidia.com" <kwankhede@nvidia.com>,
        "robin.murphy@arm.com" <robin.murphy@arm.com>,
        "kvm@vger.kernel.org" <kvm@vger.kernel.org>,
        "iommu@lists.linux-foundation.org" <iommu@lists.linux-foundation.org>,
        "dwmw2@infradead.org" <dwmw2@infradead.org>,
        "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
        "baolu.lu@linux.intel.com" <baolu.lu@linux.intel.com>,
        "nicolinc@nvidia.com" <nicolinc@nvidia.com>
Subject: RE: [RFC 08/20] vfio/pci: Add VFIO_DEVICE_BIND_IOMMUFD
Thread-Topic: [RFC 08/20] vfio/pci: Add VFIO_DEVICE_BIND_IOMMUFD
Thread-Index: AQHXrSGD1s8CLHCzb02iYFtNvU/Mhqu6lHYAgAAIGmCAAGQPgIAAqVkA
Date:   Wed, 29 Sep 2021 22:34:29 +0000
Message-ID: <BN9PR11MB543354BB34FC69D9237DED5E8CA99@BN9PR11MB5433.namprd11.prod.outlook.com>
References: <20210919063848.1476776-1-yi.l.liu@intel.com>
 <20210919063848.1476776-9-yi.l.liu@intel.com> <YVQBFgOa4fQRpwqN@yekko>
 <BN9PR11MB54331D06D97B4FC975D8D23B8CA99@BN9PR11MB5433.namprd11.prod.outlook.com>
 <20210929122801.GQ964074@nvidia.com>
In-Reply-To: <20210929122801.GQ964074@nvidia.com>
Accept-Language: en-US
Content-Language: en-US
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0: =?us-ascii?Q?SD6Nbm+2FGSZoI/v81vDBSKJ+6X0iQ29wfStZLm4M+iwml149Chft96n7Mu2?=
 =?us-ascii?Q?tdjuL5T/7Q1cgO0L5fmCsQTlX9CI98UQWmLF1rZF4ZgYvzeLI6vXuprAtszV?=
 =?us-ascii?Q?3ADN6sSxPSyrPJoqiI8dYK8Fgp19p/TbxXk6m7dPsgrw2lUjjpHWfC/7Rc+q?=
 =?us-ascii?Q?BzuJdRP871REZinrAZqv9uwr/Y8IWPac/QRscUo7vaTEU6lv71cb2eky9/7O?=
 =?us-ascii?Q?xfNwgyYyxwSTP2yTOOdq7DkqHME+nd8ujKTIAtqMb8LymCoFdFeHngblQo3M?=
 =?us-ascii?Q?5mourK9TEAOm7XodEbwta6hB1y4tX8cDz+86hFP4btkhiMsMPjC9pnLQmjjh?=
 =?us-ascii?Q?UibES5ybJ+QBVkDA75kaUzk9nK25th7IoKFGuaMy5QtQq2nNpQSfQYLI+Bdl?=
 =?us-ascii?Q?qz2Oq/iJqdKsZqCPG5+3vzZSgW9926NU0ge5piERBahsv4qersr5kh891KAd?=
 =?us-ascii?Q?5FdsoTQfsksbRljlTwco7xmL3j62HRzMgdWjTBYQ3kf+tRoL7Z7WOsprLg5O?=
 =?us-ascii?Q?fPKV/Xk73BJXI306O7BRigVQl2WWEWRiVjq+JNCo5ZBzPp0ri6gE8MP2P6K2?=
 =?us-ascii?Q?zE3+09cjoR61qNdAtnHbWRY9zajLg6NeUIFPA4rFC/5WleXLQetF7y4kRTw8?=
 =?us-ascii?Q?/jSzilgfnu3n9aPzZ9ImPRrR2UM+aMH4vhKyCEj2zTzyou1/JkIrwpQXZO7/?=
 =?us-ascii?Q?MtibS3gwf7gSVoGx4Ma5I3zi6hen+ug1kY+HXFQ/XPOJiKelPX5QVz/NOE2i?=
 =?us-ascii?Q?184aOVXmj2oBDM6A3ThXk/qBeId2DoEGRV+MuQdHQAAN8hERu5Ucul3b2hKp?=
 =?us-ascii?Q?/AYo+D35B0kjsirfsarywL20x2zgXmsov9Ybou95d88jt0YL64MRyd1n20vY?=
 =?us-ascii?Q?2ZLttanEW0GUcBAx0pSgGBVmBzKpMQX85l+w3/yjcZ/nrj4VmcE3REI7pZun?=
 =?us-ascii?Q?7bunrTnskCzNxOAz8XliRvgTqfCpF66HgKNGs08/c5T8RIBwU3vPIXe1QfBa?=
 =?us-ascii?Q?AwKOZRRpxoUE0zftb7l2KNKE94Zk53LgmQeFYXUningiwBHfHGFau5x6G5mX?=
 =?us-ascii?Q?lYKg5oG6zKW2hmL8wPfw07rW66MzKA6JJKOypm7oJ6gY2sRFgc8uL6nNP1MV?=
 =?us-ascii?Q?Q7JbJvBOENRKUZSJcAhc08x8yp55pRLpr33UJ+Nt/UOh/C3rmMPEnSq2p52z?=
 =?us-ascii?Q?rTChbIiharcsfg6uqckmuipd+hwTtpfa239yVo8mZsAd25z9i+7d7JFd0TWw?=
 =?us-ascii?Q?YYEcye7N9jvlJL8jM6OLheSq/KYXKB2buq95xCcju14oXVbTspsZ6CA4rxMp?=
 =?us-ascii?Q?QQSKm7is9AUHQBbJVbstkmnl?=
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: BN9PR11MB5433.namprd11.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 0887c62e-1049-4681-97ae-08d983994cf7
X-MS-Exchange-CrossTenant-originalarrivaltime: 29 Sep 2021 22:34:29.2831
 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 46c98d88-e344-4ed4-8496-4ed7712e255d
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: 6EzIH6KgrpzAfZ0JdZTW/QORjl3WSd/s94cOEBK78iUKqmoglLGjEnnabkXPwR0WwD41GJ/TU661YKMnMyN7MA==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN6PR11MB2019
X-OriginatorOrg: intel.com
Precedence: bulk
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

> From: Jason Gunthorpe <jgg@nvidia.com>
> Sent: Wednesday, September 29, 2021 8:28 PM
>=20
> On Wed, Sep 29, 2021 at 06:41:00AM +0000, Tian, Kevin wrote:
> > > From: David Gibson <david@gibson.dropbear.id.au>
> > > Sent: Wednesday, September 29, 2021 2:01 PM
> > >
> > > On Sun, Sep 19, 2021 at 02:38:36PM +0800, Liu Yi L wrote:
> > > > This patch adds VFIO_DEVICE_BIND_IOMMUFD for userspace to bind
> the
> > > vfio
> > > > device to an iommufd. No VFIO_DEVICE_UNBIND_IOMMUFD interface
> is
> > > provided
> > > > because it's implicitly done when the device fd is closed.
> > > >
> > > > In concept a vfio device can be bound to multiple iommufds, each
> hosting
> > > > a subset of I/O address spaces attached by this device.
> > >
> > > I really feel like this many<->many mapping between devices is going
> > > to be super-confusing, and therefore make it really hard to be
> > > confident we have all the rules right for proper isolation.
> >
> > Based on new discussion on group ownership part (patch06), I feel this
> > many<->many relationship will disappear. The context fd (either contain=
er
> > or iommufd) will uniquely mark the ownership on a physical device and
> > its group. With this design it's impractical to have one device bound
> > to multiple iommufds.
>=20
> That should be a requirement! We have no way to prove that two
> iommufds are the same security domain, so devices/groups cannot be
> shared.
>=20
> That is why the API I suggested takes in a struct file to ID the user
> security context. A group is accessible only from that single struct
> file and no more.
>=20
> If the first series goes the way I outlined then I think David's
> concern about security is strongly solved as the IOMMU layer is
> directly managing it with a very clear responsiblity and semantic.
>=20

Yes, this is also my understanding now.