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;
Date:   Wed, 29 Sep 2021 09:28:01 -0300
From:   Jason Gunthorpe <jgg@nvidia.com>
To:     "Tian, Kevin" <kevin.tian@intel.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
Message-ID: <20210929122801.GQ964074@nvidia.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>
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <BN9PR11MB54331D06D97B4FC975D8D23B8CA99@BN9PR11MB5433.namprd11.prod.outlook.com>
MIME-Version: 1.0
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0: =?us-ascii?Q?HbB6DNQO58Ol2DFY0q+tSvnjTj+wLGVZtvlXw5Qa14AWMOng5KJJUOeUEPJ+?=
 =?us-ascii?Q?kuVgBFq63IOitC43nNE4ZgNCUafsibLJLwYVkIJ4pzr7GdpXpxzG7/MXuQ0n?=
 =?us-ascii?Q?Z6cEJ8Hrot0BIPTROkrGCbCWRpoC/w7/D26KV3dxF5hr89cnJlJ4e7IRhaAh?=
 =?us-ascii?Q?JbYGZjMh1soA7+6FnMO3joJl2N3WjcIQiNd/rIUnrLZ2ReDpd7BAsTBFalbF?=
 =?us-ascii?Q?LhcAzVtwf6uuhCvFNhSMyJQAQvY3np67VXts7jUKD4lMSCQkKpRgGER7Ns8o?=
 =?us-ascii?Q?gikhE0gQXLFW/hB9Wd57jv1wJJ10GNatqve/YE6fpKl0VvAm+v5+lQWnRVLu?=
 =?us-ascii?Q?Ohm4JDNW1Pl1VpjbuWG5wU5NMFuHm6lYbtDohZVN3aANaE2Byw8AEv/eXmyD?=
 =?us-ascii?Q?He3fjUF9OakfkKlZddeDZOrZ8PF9H9cSuqYRV+JN5dInGUAfUySXX9MUSlmx?=
 =?us-ascii?Q?mIfS3vziOxWRLEl5TZZkQ/BMi0ikRJ+atyOMQ1okheFTS89B434RE7IyGeUx?=
 =?us-ascii?Q?UGOqvUyKNftLVaQkYnfA0xDlmPRj0Aksep3efcOZdxEaVfrbYm9F5vVcyW9Q?=
 =?us-ascii?Q?ukQ6fvJgH5bTpFDMaudYDDbMmvvK4e+n0T2cb7C1fUrW69zGpAkgzFq4XbJp?=
 =?us-ascii?Q?ftyavvuZDRwKr7wUGF7oLSUsd8dFbSPKfDZqRZZrCLO2A8XKjMUNdqyETkvz?=
 =?us-ascii?Q?JGhXypwqdAmkNHltB6TYY4TzXKeCjfb8duQM/0N+4PIx5Y/oX/RionCfBwuZ?=
 =?us-ascii?Q?I1UdaEO8AVBboiURJGDTqKZw3tTEU3uGJl4du8RPlAXygr4BikBrzT/o7e6o?=
 =?us-ascii?Q?BydXKg8TiTFepIZjL9QL3ZP26oF/rYbm3zmBjoA1xALvnzOe38lxvbivJbju?=
 =?us-ascii?Q?LdSfmvbVIjTJdz90Cx5w68+pNfBks27XOHI9X/wM3zew+GI4pOjnyfYXwM+4?=
 =?us-ascii?Q?RZmQEXkPuh6XbAHyqp05yZzHjQkUI8zvT8b09T5URUVuIMC1qtRFiQpQ3sJV?=
 =?us-ascii?Q?2FObxRLFB5nO+0jQACWfvzEjUsl/gCJbEjngNQ7otmU3jb+/QnjLFXuKRSTU?=
 =?us-ascii?Q?G/0Oy2O4EG4XbT7qcm+TPgeGXBYpjwHOu3rayp+ZpDU/L0++XwngJ5zZ1B1i?=
 =?us-ascii?Q?qvB1pw5nlW7g+WRaI86kwvWbghkQu+XaXls0wjRqVq70+TXlYHb6DBp+8AyX?=
 =?us-ascii?Q?XS55o1CzpXITXyqdvYL0Kd22y74CZBNaYpdXJxholwHZegoT+XdoGDmPAYsD?=
 =?us-ascii?Q?C6XPFZMiliFfz9krw/RIM5HL63ulSODbViDIVwI42Yn0V5KVuCAesDn0XlRD?=
 =?us-ascii?Q?g3K9xOMleh+X/i/kVXORKzBx?=
X-OriginatorOrg: Nvidia.com
X-MS-Exchange-CrossTenant-Network-Message-Id: b20dbf65-da1d-4ad9-4ea0-08d9834494ac
X-MS-Exchange-CrossTenant-AuthSource: BL0PR12MB5506.namprd12.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 29 Sep 2021 12:28:02.6454
 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 43083d15-7273-40c1-b7db-39efd9ccc17a
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: mZX7COAawrmfobsw8VOb4KG30Hc7lMa8JlY5Rv1+FCf8ahPZVxpBvk8+oJxaHtnV
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BL1PR12MB5141
Precedence: bulk
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

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 container
> 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. 

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.

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.

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.

Jason