From: Jason Gunthorpe <jgg@nvidia.com> To: Alex Williamson <alex.williamson@redhat.com> Cc: Joerg Roedel <joro@8bytes.org>, "Tian, Kevin" <kevin.tian@intel.com>, Jean-Philippe Brucker <jean-philippe@linaro.org>, David Gibson <david@gibson.dropbear.id.au>, Jason Wang <jasowang@redhat.com>, "parav@mellanox.com" <parav@mellanox.com>, "Enrico Weigelt, metux IT consult" <lkml@metux.net>, Paolo Bonzini <pbonzini@redhat.com>, Shenming Lu <lushenming@huawei.com>, Eric Auger <eric.auger@redhat.com>, Jonathan Corbet <corbet@lwn.net>, "Raj, Ashok" <ashok.raj@intel.com>, "Liu, Yi L" <yi.l.liu@intel.com>, "Wu, Hao" <hao.wu@intel.com>, "Jiang, Dave" <dave.jiang@intel.com>, Jacob Pan <jacob.jun.pan@linux.intel.com>, Kirti Wankhede <kwankhede@nvidia.com>, Robin Murphy <robin.murphy@arm.com>, "kvm@vger.kernel.org" <kvm@vger.kernel.org>, "iommu@lists.linux-foundation.org" <iommu@lists.linux-foundation.org>, David Woodhouse <dwmw2@infradead.org>, LKML <linux-kernel@vger.kernel.org>, Lu Baolu <baolu.lu@linux.intel.com> Subject: Re: Plan for /dev/ioasid RFC v2 Date: Wed, 9 Jun 2021 15:49:40 -0300 [thread overview] Message-ID: <20210609184940.GH1002214@nvidia.com> (raw) In-Reply-To: <20210609102722.5abf62e1.alex.williamson@redhat.com> On Wed, Jun 09, 2021 at 10:27:22AM -0600, Alex Williamson wrote: > > > It is a kernel decision, because a fundamental task of the kernel is to > > > ensure isolation between user-space tasks as good as it can. And if a > > > device assigned to one task can interfer with a device of another task > > > (e.g. by sending P2P messages), then the promise of isolation is broken. > > > > AIUI, the IOASID model will still enforce IOMMU groups, but it's not an > > explicit part of the interface like it is for vfio. For example the > > IOASID model allows attaching individual devices such that we have > > granularity to create per device IOASIDs, but all devices within an > > IOMMU group are required to be attached to an IOASID before they can be > > used. Yes, thanks Alex > > It's not entirely clear to me yet how that last bit gets > > implemented though, ie. what barrier is in place to prevent device > > usage prior to reaching this viable state. The major security checkpoint for the group is on the VFIO side. We must require the group before userspace can be allowed access to any device registers. Obtaining the device_fd from the group_fd does this today as the group_fd is the security proof. Actually, thinking about this some more.. If the only way to get a working device_fd in the first place is to get it from the group_fd and thus pass a group-based security check, why do we need to do anything at the ioasid level? The security concept of isolation was satisfied as soon as userspace opened the group_fd. What do more checks in the kernel accomplish? Yes, we have the issue where some groups require all devices to use the same IOASID, but once someone has the group_fd that is no longer a security issue. We can fail VFIO_DEVICE_ATTACH_IOASID callss that don't make sense. > > > > Groups should be primarily about isolation security, not about IOASID > > > > matching. > > > > > > That doesn't make any sense, what do you mean by 'IOASID matching'? > > > > One of the problems with the vfio interface use of groups is that we > > conflate the IOMMU group for both isolation and granularity. I think > > what Jason is referring to here is that we still want groups to be the > > basis of isolation, but we don't want a uAPI that presumes all devices > > within the group must use the same IOASID. Yes, thanks again Alex > > For example, if a user owns an IOMMU group consisting of > > non-isolated functions of a multi-function device, they should be > > able to create a vIOMMU VM where each of those functions has its > > own address space. That can't be done today, the entire group > > would need to be attached to the VM under a PCIe-to-PCI bridge to > > reflect the address space limitation imposed by the vfio group > > uAPI model. Thanks, > > Hmm, likely discussed previously in these threads, but I can't come up > with the argument that prevents us from making the BIND interface > at the group level but the ATTACH interface at the device level? For > example: > > - VFIO_GROUP_BIND_IOASID_FD > - VFIO_DEVICE_ATTACH_IOASID > > AFAICT that makes the group ownership more explicit but still allows > the device level IOASID granularity. Logically this is just an > internal iommu_group_for_each_dev() in the BIND ioctl. Thanks, At a high level it sounds OK. However I think your above question needs to be answered - what do we want to enforce on the iommu_fd and why? Also, this creates a problem with the device label idea, we still need to associate each device_fd with a label, so your above sequence is probably: VFIO_GROUP_BIND_IOASID_FD(group fd) VFIO_BIND_IOASID_FD(device fd 1, device_label) VFIO_BIND_IOASID_FD(device fd 2, device_label) VFIO_DEVICE_ATTACH_IOASID(..) And then I think we are back to where I had started, we can trigger whatever VFIO_GROUP_BIND_IOASID_FD does automatically as soon as all of the devices in the group have been bound. Jason
WARNING: multiple messages have this Message-ID (diff)
From: Jason Gunthorpe <jgg@nvidia.com> To: Alex Williamson <alex.williamson@redhat.com> Cc: "kvm@vger.kernel.org" <kvm@vger.kernel.org>, Jason Wang <jasowang@redhat.com>, Kirti Wankhede <kwankhede@nvidia.com>, Jean-Philippe Brucker <jean-philippe@linaro.org>, "Jiang, Dave" <dave.jiang@intel.com>, "Raj, Ashok" <ashok.raj@intel.com>, Jonathan Corbet <corbet@lwn.net>, "Tian, Kevin" <kevin.tian@intel.com>, "parav@mellanox.com" <parav@mellanox.com>, "Enrico Weigelt, metux IT consult" <lkml@metux.net>, David Gibson <david@gibson.dropbear.id.au>, Robin Murphy <robin.murphy@arm.com>, LKML <linux-kernel@vger.kernel.org>, Shenming Lu <lushenming@huawei.com>, "iommu@lists.linux-foundation.org" <iommu@lists.linux-foundation.org>, Paolo Bonzini <pbonzini@redhat.com>, David Woodhouse <dwmw2@infradead.org> Subject: Re: Plan for /dev/ioasid RFC v2 Date: Wed, 9 Jun 2021 15:49:40 -0300 [thread overview] Message-ID: <20210609184940.GH1002214@nvidia.com> (raw) In-Reply-To: <20210609102722.5abf62e1.alex.williamson@redhat.com> On Wed, Jun 09, 2021 at 10:27:22AM -0600, Alex Williamson wrote: > > > It is a kernel decision, because a fundamental task of the kernel is to > > > ensure isolation between user-space tasks as good as it can. And if a > > > device assigned to one task can interfer with a device of another task > > > (e.g. by sending P2P messages), then the promise of isolation is broken. > > > > AIUI, the IOASID model will still enforce IOMMU groups, but it's not an > > explicit part of the interface like it is for vfio. For example the > > IOASID model allows attaching individual devices such that we have > > granularity to create per device IOASIDs, but all devices within an > > IOMMU group are required to be attached to an IOASID before they can be > > used. Yes, thanks Alex > > It's not entirely clear to me yet how that last bit gets > > implemented though, ie. what barrier is in place to prevent device > > usage prior to reaching this viable state. The major security checkpoint for the group is on the VFIO side. We must require the group before userspace can be allowed access to any device registers. Obtaining the device_fd from the group_fd does this today as the group_fd is the security proof. Actually, thinking about this some more.. If the only way to get a working device_fd in the first place is to get it from the group_fd and thus pass a group-based security check, why do we need to do anything at the ioasid level? The security concept of isolation was satisfied as soon as userspace opened the group_fd. What do more checks in the kernel accomplish? Yes, we have the issue where some groups require all devices to use the same IOASID, but once someone has the group_fd that is no longer a security issue. We can fail VFIO_DEVICE_ATTACH_IOASID callss that don't make sense. > > > > Groups should be primarily about isolation security, not about IOASID > > > > matching. > > > > > > That doesn't make any sense, what do you mean by 'IOASID matching'? > > > > One of the problems with the vfio interface use of groups is that we > > conflate the IOMMU group for both isolation and granularity. I think > > what Jason is referring to here is that we still want groups to be the > > basis of isolation, but we don't want a uAPI that presumes all devices > > within the group must use the same IOASID. Yes, thanks again Alex > > For example, if a user owns an IOMMU group consisting of > > non-isolated functions of a multi-function device, they should be > > able to create a vIOMMU VM where each of those functions has its > > own address space. That can't be done today, the entire group > > would need to be attached to the VM under a PCIe-to-PCI bridge to > > reflect the address space limitation imposed by the vfio group > > uAPI model. Thanks, > > Hmm, likely discussed previously in these threads, but I can't come up > with the argument that prevents us from making the BIND interface > at the group level but the ATTACH interface at the device level? For > example: > > - VFIO_GROUP_BIND_IOASID_FD > - VFIO_DEVICE_ATTACH_IOASID > > AFAICT that makes the group ownership more explicit but still allows > the device level IOASID granularity. Logically this is just an > internal iommu_group_for_each_dev() in the BIND ioctl. Thanks, At a high level it sounds OK. However I think your above question needs to be answered - what do we want to enforce on the iommu_fd and why? Also, this creates a problem with the device label idea, we still need to associate each device_fd with a label, so your above sequence is probably: VFIO_GROUP_BIND_IOASID_FD(group fd) VFIO_BIND_IOASID_FD(device fd 1, device_label) VFIO_BIND_IOASID_FD(device fd 2, device_label) VFIO_DEVICE_ATTACH_IOASID(..) And then I think we are back to where I had started, we can trigger whatever VFIO_GROUP_BIND_IOASID_FD does automatically as soon as all of the devices in the group have been bound. Jason _______________________________________________ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
next prev parent reply other threads:[~2021-06-09 18:49 UTC|newest] Thread overview: 162+ messages / expand[flat|nested] mbox.gz Atom feed top 2021-06-07 2:58 Plan for /dev/ioasid RFC v2 Tian, Kevin 2021-06-07 2:58 ` Tian, Kevin 2021-06-09 8:14 ` Eric Auger 2021-06-09 8:14 ` Eric Auger 2021-06-09 9:37 ` Tian, Kevin 2021-06-09 9:37 ` Tian, Kevin 2021-06-09 10:14 ` Eric Auger 2021-06-09 10:14 ` Eric Auger 2021-06-09 9:01 ` Leon Romanovsky 2021-06-09 9:01 ` Leon Romanovsky 2021-06-09 9:43 ` Tian, Kevin 2021-06-09 9:43 ` Tian, Kevin 2021-06-09 12:24 ` Joerg Roedel 2021-06-09 12:24 ` Joerg Roedel 2021-06-09 12:39 ` Jason Gunthorpe 2021-06-09 12:39 ` Jason Gunthorpe 2021-06-09 13:32 ` Joerg Roedel 2021-06-09 13:32 ` Joerg Roedel 2021-06-09 15:00 ` Jason Gunthorpe 2021-06-09 15:00 ` Jason Gunthorpe 2021-06-09 15:51 ` Joerg Roedel 2021-06-09 15:51 ` Joerg Roedel 2021-06-09 16:15 ` Alex Williamson 2021-06-09 16:15 ` Alex Williamson 2021-06-09 16:27 ` Alex Williamson 2021-06-09 16:27 ` Alex Williamson 2021-06-09 18:49 ` Jason Gunthorpe [this message] 2021-06-09 18:49 ` Jason Gunthorpe 2021-06-10 15:38 ` Alex Williamson 2021-06-10 15:38 ` Alex Williamson 2021-06-11 0:58 ` Tian, Kevin 2021-06-11 0:58 ` Tian, Kevin 2021-06-11 21:38 ` Alex Williamson 2021-06-11 21:38 ` Alex Williamson 2021-06-14 3:09 ` Tian, Kevin 2021-06-14 3:09 ` Tian, Kevin 2021-06-14 3:22 ` Alex Williamson 2021-06-14 3:22 ` Alex Williamson 2021-06-15 1:05 ` Tian, Kevin 2021-06-15 1:05 ` Tian, Kevin 2021-06-14 13:38 ` Jason Gunthorpe 2021-06-14 13:38 ` Jason Gunthorpe 2021-06-15 1:21 ` Tian, Kevin 2021-06-15 1:21 ` Tian, Kevin 2021-06-15 16:56 ` Alex Williamson 2021-06-15 16:56 ` Alex Williamson 2021-06-16 6:53 ` Tian, Kevin 2021-06-16 6:53 ` Tian, Kevin 2021-06-24 4:50 ` David Gibson 2021-06-24 4:50 ` David Gibson 2021-06-11 16:45 ` Jason Gunthorpe 2021-06-11 16:45 ` Jason Gunthorpe 2021-06-11 19:38 ` Alex Williamson 2021-06-11 19:38 ` Alex Williamson 2021-06-12 1:28 ` Jason Gunthorpe 2021-06-12 1:28 ` Jason Gunthorpe 2021-06-12 16:57 ` Alex Williamson 2021-06-12 16:57 ` Alex Williamson 2021-06-14 14:07 ` Jason Gunthorpe 2021-06-14 14:07 ` Jason Gunthorpe 2021-06-14 16:28 ` Alex Williamson 2021-06-14 16:28 ` Alex Williamson 2021-06-14 19:40 ` Jason Gunthorpe 2021-06-14 19:40 ` Jason Gunthorpe 2021-06-15 2:31 ` Tian, Kevin 2021-06-15 2:31 ` Tian, Kevin 2021-06-15 16:12 ` Alex Williamson 2021-06-15 16:12 ` Alex Williamson 2021-06-16 6:43 ` Tian, Kevin 2021-06-16 6:43 ` Tian, Kevin 2021-06-16 19:39 ` Alex Williamson 2021-06-16 19:39 ` Alex Williamson 2021-06-17 3:39 ` Liu Yi L 2021-06-17 3:39 ` Liu Yi L 2021-06-17 7:31 ` Tian, Kevin 2021-06-17 7:31 ` Tian, Kevin 2021-06-17 21:14 ` Alex Williamson 2021-06-17 21:14 ` Alex Williamson 2021-06-18 0:19 ` Jason Gunthorpe 2021-06-18 0:19 ` Jason Gunthorpe 2021-06-18 16:57 ` Tian, Kevin 2021-06-18 16:57 ` Tian, Kevin 2021-06-18 18:23 ` Jason Gunthorpe 2021-06-18 18:23 ` Jason Gunthorpe 2021-06-25 10:27 ` Tian, Kevin 2021-06-25 10:27 ` Tian, Kevin 2021-06-25 14:36 ` Jason Gunthorpe 2021-06-25 14:36 ` Jason Gunthorpe 2021-06-28 1:09 ` Tian, Kevin 2021-06-28 1:09 ` Tian, Kevin 2021-06-28 22:31 ` Alex Williamson 2021-06-28 22:31 ` Alex Williamson 2021-06-28 22:48 ` Jason Gunthorpe 2021-06-28 22:48 ` Jason Gunthorpe 2021-06-28 23:09 ` Alex Williamson 2021-06-28 23:09 ` Alex Williamson 2021-06-28 23:13 ` Jason Gunthorpe 2021-06-28 23:13 ` Jason Gunthorpe 2021-06-29 0:26 ` Tian, Kevin 2021-06-29 0:26 ` Tian, Kevin 2021-06-29 0:28 ` Tian, Kevin 2021-06-29 0:28 ` Tian, Kevin 2021-06-29 0:43 ` Tian, Kevin 2021-06-29 0:43 ` Tian, Kevin 2021-06-28 2:03 ` Tian, Kevin 2021-06-28 2:03 ` Tian, Kevin 2021-06-28 14:41 ` Jason Gunthorpe 2021-06-28 14:41 ` Jason Gunthorpe 2021-06-28 6:45 ` Tian, Kevin 2021-06-28 6:45 ` Tian, Kevin 2021-06-28 16:26 ` Jason Gunthorpe 2021-06-28 16:26 ` Jason Gunthorpe 2021-06-24 4:26 ` David Gibson 2021-06-24 4:26 ` David Gibson 2021-06-24 5:59 ` Tian, Kevin 2021-06-24 5:59 ` Tian, Kevin 2021-06-24 12:22 ` Lu Baolu 2021-06-24 12:22 ` Lu Baolu 2021-06-24 4:23 ` David Gibson 2021-06-24 4:23 ` David Gibson 2021-06-18 0:52 ` Jason Gunthorpe 2021-06-18 0:52 ` Jason Gunthorpe 2021-06-18 13:47 ` Joerg Roedel 2021-06-18 13:47 ` Joerg Roedel 2021-06-18 15:15 ` Jason Gunthorpe 2021-06-18 15:15 ` Jason Gunthorpe 2021-06-18 15:37 ` Raj, Ashok 2021-06-18 15:37 ` Raj, Ashok 2021-06-18 15:51 ` Alex Williamson 2021-06-18 15:51 ` Alex Williamson 2021-06-24 4:29 ` David Gibson 2021-06-24 4:29 ` David Gibson 2021-06-24 11:56 ` Jason Gunthorpe 2021-06-24 11:56 ` Jason Gunthorpe 2021-06-18 0:10 ` Jason Gunthorpe 2021-06-18 0:10 ` Jason Gunthorpe 2021-06-17 5:29 ` David Gibson 2021-06-17 5:29 ` David Gibson 2021-06-17 5:02 ` David Gibson 2021-06-17 5:02 ` David Gibson 2021-06-17 23:04 ` Jason Gunthorpe 2021-06-17 23:04 ` Jason Gunthorpe 2021-06-24 4:37 ` David Gibson 2021-06-24 4:37 ` David Gibson 2021-06-24 11:57 ` Jason Gunthorpe 2021-06-24 11:57 ` Jason Gunthorpe 2021-06-10 5:50 ` Lu Baolu 2021-06-10 5:50 ` Lu Baolu 2021-06-17 5:22 ` David Gibson 2021-06-17 5:22 ` David Gibson 2021-06-18 5:21 ` Lu Baolu 2021-06-18 5:21 ` Lu Baolu 2021-06-24 4:03 ` David Gibson 2021-06-24 4:03 ` David Gibson 2021-06-24 13:42 ` Lu Baolu 2021-06-24 13:42 ` Lu Baolu 2021-06-17 4:45 ` David Gibson 2021-06-17 4:45 ` David Gibson 2021-06-17 23:10 ` Jason Gunthorpe 2021-06-17 23:10 ` Jason Gunthorpe 2021-06-24 4:07 ` David Gibson 2021-06-24 4:07 ` David Gibson
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=20210609184940.GH1002214@nvidia.com \ --to=jgg@nvidia.com \ --cc=alex.williamson@redhat.com \ --cc=ashok.raj@intel.com \ --cc=baolu.lu@linux.intel.com \ --cc=corbet@lwn.net \ --cc=dave.jiang@intel.com \ --cc=david@gibson.dropbear.id.au \ --cc=dwmw2@infradead.org \ --cc=eric.auger@redhat.com \ --cc=hao.wu@intel.com \ --cc=iommu@lists.linux-foundation.org \ --cc=jacob.jun.pan@linux.intel.com \ --cc=jasowang@redhat.com \ --cc=jean-philippe@linaro.org \ --cc=joro@8bytes.org \ --cc=kevin.tian@intel.com \ --cc=kvm@vger.kernel.org \ --cc=kwankhede@nvidia.com \ --cc=linux-kernel@vger.kernel.org \ --cc=lkml@metux.net \ --cc=lushenming@huawei.com \ --cc=parav@mellanox.com \ --cc=pbonzini@redhat.com \ --cc=robin.murphy@arm.com \ --cc=yi.l.liu@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: linkBe 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.